Support for milliseconds (songlengths.md5)

[Tekl]

I compiled sidplayfp 2.1.1 on my M1 MacBook (ARM). Sidplayfp supports the new songlengths.md5 format but it seems to round the lengths by seconds and ignores the milliseconds. Maybe there's an option to make sidplayfp more accurate, but I haven't found it.

It would be great if you can fix this in a future release of sidplayfp. On the Mac I only found Java SID Player Music Library V2 that will respect milliseconds in the lengths.

[drfiemost]

The new songlengths DB format is already supported but milliseconds are not displayed and not recognized for -b and -t options. Will fix this in the next release

[drfiemost]

It's now done in master if you want to give it a try.

[Tekl]

Thanks for the fast fix. There must be a bug in parsing the songlengths file. For example I've the value "0:23.079". Sidplayfp makes "0:23.790" of it. Using "-t0:23.079" seems to work but the length of the exported wave file is still 0:24.000. Also the playback seems not to stop exactly at 0:23.079 (compared to the wav file).

Take "/MUSICIANS/N/Nebula/Tune_2.sid" for example. I exported it to wav and measured the exact lenght with an wav editor (ocenaudio). The song should stop at 0:30.762. I edited the sonlenght file and sidplayfp shows the correct value, but the playback is a little bit longer than expected. Btw. Java SIDPlay 2 does it right.

[drfiemost]

Thank you for testing. I can confirm the -t problem, it's due to the buffer size fixed at one second.
I don't see the other issues, can you specify the steps to reproduce, please? (And BTW, here with HVSC #74 Tune_2 is 16 seconds long)

[Tekl]

I'm trying to correct the values in HVSC, that's because the official values are currently different. To reproduce the issue with the changing milliseconds, edit this entry in the Songlengths.md5:

; /MUSICIANS/N/Nebula/Groovy.sid
53811c41e0a243820e996932daf1d84c=0:23.079

It seems that sidplayfp removes the leading 0 of the milliseconds.

[drfiemost]

This should be fixed in master, I cannot reproduce it anymore.

Edit: this actually was a bug in the library, fixed with libsidplayfp/libsidplayfp@3c54725

[Tekl]

Great. It seems to be fixed. The playback hasn't changed, right? You're speaking of a 1 sec buffer. The tunes play well, when I substract around 75 milliseconds, not a whole second.

[drfiemost]

The playback is still broken. The wav writer uses a bigger buffer as there are no latency problems while other output methods have smaller buffers, depending on platform. But at the moments writes smaller than buffer size are not supported so the song ending is not precise as it should.

[drfiemost]

Tried to progress a bit on this in the new branch "milliseconds". Results are still disappointing though :/