gapless in Winamp - not gapless in Rockbox?

[Lear]

I asked one of the Nero developers ages ago about how they stored their gapless info and he said the documentation is the faad source code.

I got a similar reply when I tried. I spent some time looking for how faad did it, but found nothing useful.

[markun]

By looking at the VLC sourecode, the FLV specs (chapters there are almost the same) and some trial and error I think I managed to implement gapless playback of Nero encoded AAC files:

http://www.rockbox.org/tracker/task/10655

Please test and comment on problems with the code

[Lear]

So the Nero encoder still does that? I seem to remember reading something about that being removed, or maybe just that there was a better way of doing it...

Oh well, as long it works. It isn't much code.

[markun]

So the Nero encoder still does that? I seem to remember reading something about that being removed, or maybe just that there was a better way of doing it...

I used neroAacEnc.exe version 1.3.3.0 which seems to be from 2008-9-17, not sure if it was changed after that. Can you find some more info about it?
This worked for the files I created and for the test files from zfox.

[zfox]

1.3.3.0 is the latest version. The next one will be released in the next 2 or 3 months as 2 nero developers have mentioned in hydrogenaudio.org.

[markun]

It's in SVN now. Let me know if there are any problems.

[zfox]

I tested the SVN build with about 15 live albums and it seems to work as expected. Thank you very much for the patch and your time.

The 'startTime' attribute has always the value '00:00:00.059' no matter what the audio length of the file is and the version of the encoder being used. Examining the file with Audacity, I can see a gap of about 0.059xx seconds that differs from file to file. The stored value seems to keep only the first three decimal digits of the actual value. I guess that this is normal behavior. That loss of precision cannot be heard at 98% of times.

Thanks again.

[markun]

actually the precision is 10,000,000th of a second. Could it be a rounding problem? (don't know if you could hear a 1 sample difference) Or is the value rounded to three decimals before multiplying by 10000000? I can check it later.