DiscoHawk corrupts the last track

[Meerkov]

1) Try to use DiscoHawk to extract MP3s from Block Buster (Europe) for the PS1 2) Notice that Track 06 and Track 07 are nearly identical, but Track 7 is 2 seconds shorter. 3) Check the original Track 06.bin and calculate the SHA1 of that file 4) Repeat for Track 7 and compare them. 5) Notice that the sha1 of both Track 06 and Track 07 is 9700d4302a3da1706f60a7a352d061c31a3c1a2a

Result: DiscoHawk removed 2 seconds from the final track on the disk, even though it's byte-for-byte identical to the previous track. This is not the only time I've seen this, but this was the first time I checked the SHA1s.

[Meerkov]

I leave open the possibility this is working-as-intended, and that the track length is defined somewhere else. :)

[Meerkov]

Another game with the same thing: The Bombing Islands. Track 10 and 11 are identical, but produce two different MP3s (Track 11 is 2 seconds shorter).

I don't know if this is just a fluke of the copies of the games that I have, but it's really strange that I see this a lot.

[getCursorsExe]

This is probably FFmpeg decoder bug.

[Meerkov]

Might be worth double checking that. I've been playing with DiscoHawk enough that I can probably try to double check if I bypass DiscoHawk and make the calls myself if I get the same result.

Last I checked, it looks like DiscoHawk does a re-encoding step prior to sending the file to FFMPEG, so the problem might be there too. (ffmpeg is called with a file like "tmp6969.tmp" rather than the original track file, and the tmp file and original track are not identical files).

[Meerkov]

@YoshiRulz honestly, assign this to me, and I will find time to debug it. I think now that it's a couple months later, I understand DiscoHawk and FFMPEG enough to fix this one.