#6883 Scummvm can get confused by cd audio if there is a cd inserted when trying to run a game

[i30817]

I was testing the cd rip of gobliiins i'd just done and was getting loom cd audio. This was probably because i had the loom cd inserted and the ripper called the goblins audio track track02.wav.

Just FYI.

[i30817]

I really think scummvm should parse cue files when it finds it instead for both dosbox data inter-compatibility and naming the ogg/mp3/flac tracks whatever the user wants. I realize it would be impossible to have canonical signatures of cue files, but the situation with tracks is already the same and there are more of them. i'd prefer renaming one file to a canonical name than to juggle false positives everywhere on the game directory tree.

BTW, the above was for a 'mass add' only in the Gobliiins dir (not the hypotetical above), the cd always takes precedence apparently.

Moreover I'd like to keep the cds/cd audio separate from the install game files, and scummvm (even with mass add) does not support that, probably to try to eliminate these false positives. I don't really see the point of that with canonical cue files.

[i30817]

On second thought no skin off my back if you don't want to support it. I can always symlink.

[Torbjörn Andersson]

Is this really a bug? I could be wrong, but as far as I know, ScummVM does look for a ripped version of the audio track first, and only tries to play it from the CD if it can't find one. But it wouldn't find your track02.wav, because it doesn't look for WAV files.

In case that was a typo and you meant track02.flac or .mp3 or .ogg or whatever, and the problem is that ScummVM expects the first audio track to be numbered 1 instead of 2, couldn't you simply change the .cue file you're using with DOSBox so that they look for the same file?

[Eugene Sandulenko]

As discussed on IRC, no, we will not support that.