What did you specificly change so that games like BAK are broken ? The cue file doesn't look that bad to me. Why is extra bookkeeping needed about what the game uses ?
Pr3tty F1y, interesting history about people wrestling with Castlevania and getting it working through cue manipulation! You knew exactly what was going on with Krondor.
Yes; it's too bad buyers of GoG games aren't given the option to download archival images of the floppies or CDs. I can image a decent percent of users have original hardware and would prefer to install from hard media, instead of transplanting their post-installed game files after clicking through GoG's installer on a modern PC.
Qbix, I only have a mode 1/2048 BIN+CUE, and used bchunk to rip it to individual tracks. The content in those resulting tracks doesn't match with what the game expects to play.
A check for this would activate when the game queries for a track number's MSF offset. It would record the track# as the 'last queried track number'.
Then, when the game requests playback at an MSF offset (and DOSBox subsequently calculates which ogg/wav file that offset lands within), the check would compare this 'actual track' number against the 'last queried track number' and report if they mismatch.
This check would ignore the common scenario where games query each track's MSF time in monotonically increasing or decreasing order; so we would not record the 'last queried track number' on back-to-back queries.
We'd also ignore scenarios where back-to-back playback requests are made without a corresponding query for a track's MSF offset in between.
Probably other false-positive patterns too; but atleast it would catch this particular cue problem in BaK.
I meant what did you change so that the currently working! cue/ogg/mp3 setup of this specific game doesn't work with your patch ?
It is a regression that a working setup stops working after adding your patch.
When I rip my BIN to oggs, neither SVN or ECE can mount the resulting CUE. If someone is willing to send me their mountable oggs+cue, I'm happy to investigate!
Using ECE r4290 it will mount my cue with the tracks ripped to OGGs, but does not play them. Using yesterplay's plain SVN r4290 build it will mount the cue and play the OGGs in game. This is on Win7, not Linux. The cue is the one I wrote for my BaK installer. I will note that the ISO is a dummy one since all of the game files are in the installed directory.
Here's what's going on with Betrayal at Krondor (GoG edition).
Audio track inspection: Please listen to the end of
OGG Track 15 and the start of Track 16.
The end of 15 actually contains a bit more than 2 seconds of "extra" silence, including the first bit of track 16's audio! Track 16 has no "lead up"; it's playing from the get-go.
Game behavior:
The game asks for the minute-second-frame (MSF) for the track number it wants to play, which is Track 16 for the intro sequence.
DOSBox returns Track 16's MSF value of 22:33:22 back to the game, which equates to a sector offset of 101497
The game subtracts 189 sectors (or 2.52 seconds) from this value, which logically becomes the very end of Track 15.
The game asks to play at this deducted location (Track 16 minus 2.52 seconds) for a duration of 44.64 seconds.
Here are the two MSCDEX calls Krondor makes (GetAudioTrackInfo and PlayAudioSector), plus the internal query to GetTrack(); I've slightly adjusted my current debug statements, so yours might look different:
118:01:04 CDROM: GetAudioTrackInfo(queried MSF for track 16), returned MSF 22:33:22 (sector 101497) with attr=0 218:01:04 CDROM: GetTrack(sector 101308) lands at MSF 22:30:58 in track 15 that starts at 96546 and ends at 101347 318:01:04 CDROM: PlayAudioSector(at sector 101308 for 3348 sectors) inside track 15 that starts at 96546 and ends at 101347
Observations:
Notice that the game wants to play sector 101308, which is Track 15, but Track 15 ends a mere 39 sectors later, at sector 101347. You might ask, what happened to the 189 frames? Where did 150 of them disappear to? This is because DOSBox internally pads the start each track by 2 seconds (or 150 frames) so these "eat up" 150 of them, leaving us 39 frames into the tail-end of Track 15.
So we start to see what's going on.. the game starts playing Track 15 just a split seconds before it ends, however the game believes the track will carry on for 44.6 seconds!
How ECE and SVN differ:
ECE treats each file's track as its own sequence, and only will play up-to the end of the file. So if a game tries to a play beyond the track (which can happen in small quantities due to rounding errors or the compressed track being a hair shorter than the binary data), then ECE stops the track playback when no more data can be read from the track.
SVN treats each 2352-byte sector as its own independent read: it seeks to the desired sector, reads 2352 bytes, and then repeats. If data isn't available or not "playing", it fills in those 2352-bytes with silence and plays that instead. So we see this behavior allows "reading beyond" a given track; if the compressed track comes up short or the game asks for a bit longer playback then the track actually has, then SVN plays from the start of the next track.
So the immediate fix would be to make the audio patch used by ECE behave similarly. That said, I do have some reservations/questions:
First, this is the only CD-DA game I've seen with this behavior.. where it plays the last split second of the prior track and relies on "reading beyond" by almost the entire next track's duration
Second, I have to question the RIP -- why are the final ~2.5 seconds of each track actually the start of the subsequent track?
If the RIP is perfectly accurate, then these slightly shifted tracks would exist in the physical CD, so perhaps this "subtract 189 frame" behavior was made by the game developers to compensate for the audio CD pressing results. ie: We can rebuild him, we have the technology...the last minute software hack to work around physical issues that would be prohibitive to fix.
In the end though, if MSCDEX's specification says that playing-beyond a track's duration is legal and should flow into the subsequent track - then indeed, the patch will need to be updated.
A work-around also exists (avoiding the need for ECE to cater to this), which is converting the OGGs into PCM tracks and concatenating them to the data track, and creating a CUE; as we know ECE has no issues with the BIN/CUE release.
Sorry for the wall of text.. thanks for making it through, and curious what you think.
If you look at the believed-to-be-good dumps at re****.org, the 1.02 version has standard pregap (2 seconds = 150 frames) on the first audio track while the (presumably) earlier version has non-standard pregap across most, but not all, audio tracks. It's possible that some versions of the game compensate for what might be a disc mastering issue. Also, some ripping/imaging software mishandles pregap, leading to a 2 second "shift" in audio track start/end -- I've encountered a few images where that seems to have happened.
Anyway, when playing goes past the end of a track it should continue on to the next, and the next, and so on, until the play-length is reached.
Revision 14 of the audio patch has been posted, along with changelog here: AUDIO Patch supporting FLAC, Opus, and MP3 audio tracks
This fixes Betrayal at Krondor and Destruction Derby (both when using file-based audio tracks).
The code as-patched has been tested to build under the following:
- Windows - VisualStudio 32-bit target
- Windows - MSYS2, GCC 32-bit and 64-bit targets
- Windows - MSYS2, Clang 32-bit and 64-bit targets
- macOS - Xcode Clang
- macOS - Brew GCC-9
- Ubuntu 16.04 - GCC-5
- Ubuntu 18.04 - GCC-7
- Ubuntu 18.04 - GCC-9
- Ubuntu 18.04 - Clang-8
Ah, thank for the hint. However, I can't copmpile opusfile because of missing autoconf files for pkg-config, which isn't available for MSYS/MINGW... Time to get the MSYS2 environment working... So, for the time being, ECE will be stuck on Rev. 13 of your patch until I can compile it under MSYS2.
Ah, thank for the hint. However, I can't copmpile opusfile because of missing autoconf files for pkg-config, which isn't available for MSYS/MINGW... Time to get the MSYS2 environment working... So, for the time being, ECE will be stuck on Rev. 13 of your patch until I can compile it under MSYS2.
Have you considered using Visual Studio 2019 + vcpkg for Windows builds? If yes, but you opted to MSYS/MINGW instead - were there any technical reasons? We have both MSYS2 and VS2019 setup working via CI in dosbox-staging, so feel free to copy whatever you need.
If you want, I can give you push access to my repo, so you could store your patch series (which is super helpful btw, your work is indispensable to the community) as a Git branch (it would make it easier to rebase your series on top of new changes from SVN, if you know your way around git-rebase).
We also have this pull-request in progress that will let you build Opusfile and friends statically, and then pass through ./configure without the need for pkg-config.
If you want to give it a try before we merge, you can download the Makefile into your msys environment, `make -j4`, and then set the environment variables as it describes (paths should be absolute, so its location is independent from the DOSBox source directory).
Your resulting DOSBox binary will have all its audio codecs internal to it, but because SDL and other libraries link with even more libraries, the DOSBox binary will superficially appear to have lots of codec dependencies (and compression libraries like lz4, lzma, ... and so on).
Have you considered using Visual Studio 2019 + vcpkg for Windows builds? If yes, but you opted to MSYS/MINGW instead - were there any technical reasons? We have both MSYS2 and VS2019 setup working via CI in dosbox-staging, so feel free to copy whatever you need.
I tried using it at the beginning but something, I can't even remember what it was, didn't work, so I followed the guide in the official wiki and set everything up using MINGW. For someone like me, without any programming and development skills, it was a good way to start and it was helpful because it also made reproducing the required steps in Linux much easier, because it's so similar. And in the meantime I got used to it and can create a new build with the start of just one shell script per OS.
dreamer_ wrote:
If you want, I can give you push access to my repo, so you could store your patch series (which is super helpful btw, your work is indispensable to the community) as a Git branch (it would make it easier to rebase your series on top of new changes from SVN, if you know your way around git-rebase).
TBH: I don't have the slightest idea how to use GIT or any of its tools, I made an account once to put my code there, but I still didn't find the time to get into the whole matter. 😢
I wonder if this possible - that dosbox vsync will be enabled only when ingame fps is 60 fps or lower, when fps go above 60 (to 70 usual) - vsync will be automatically disabled (ie something like adaptive nvidia sync 😎)
OR if vsync can be enabled on the fly with some key combination (so you can enable-disable it when you need it, without slowing down menus/music during 70 fps parts)
I wonder if this possible - that dosbox vsync will be enabled only when ingame fps is 60 fps or lower, when fps go above 60 (to 70 usual) - vsync will be automatically disabled (ie something like adaptive nvidia sync 😎)
OR if vsync can be enabled on the fly with some key combination (so you can enable-disable it when you need it, without slowing down menus/music during 70 fps parts)
I don't think that's even remotely possible since vsync flags have to be passed to SDL when the window is created.
I wonder if this possible - that dosbox vsync will be enabled only when ingame fps is 60 fps or lower, when fps go above 60 (to 70 usual) - vsync will be automatically disabled (ie something like adaptive nvidia sync 😎)
OR if vsync can be enabled on the fly with some key combination (so you can enable-disable it when you need it, without slowing down menus/music during 70 fps parts)
I don't think that's even remotely possible since vsync flags have to be passed to SDL when the window is created.
I thought so (but you'll never know..maybe in the future 😎 )
I wonder if this possible - that dosbox vsync will be enabled only when ingame fps is 60 fps or lower, when fps go above 60 (to 70 usual) - vsync will be automatically disabled (ie something like adaptive nvidia sync 😎)
OR if vsync can be enabled on the fly with some key combination (so you can enable-disable it when you need it, without slowing down menus/music during 70 fps parts)
I don't think that's even remotely possible since vsync flags have to be passed to SDL when the window is created.
I thought so (but you'll never know..maybe in the future 😎 )