bogus audio + spike when encoding gaples WAVs

[calestyo]

Hey.

I have some WAV files from tracks from a CD which would play gapless, which does work perfectly when playing them back via mpv. It also works when playing lame encoded MP3s from them, at least in mpv and on the ipod (many other players, e.g. mplayer or totem seem to not support gapless playback at all).

Since AAC is more advanced I tried to use that with fdkaac using version 0.6.2 and from libfdk-aac 0.1.4 with those commands: fdkaac -p 2 -G 2 -m 5 1.wav -o fdkaac-lc-gap2-vbr5_1.m4a fdkaac -p 2 -G 2 -m 5 2.wav -o fdkaac-lc-gap2-vbr5_2.m4a (I also tried -p 5 and 29, and then everything with -G 0, but the problem looks just the same there).

When comparing the ends 1.wav with fdkaac-lc-gap2-vbr5_1.m4a it looks like this: (and the beginning of the to tracks is perfectly aligned) As you can see, the AAC has some audio and a nasty spike added (the spike looks different for LC, HE and HE2).

Comparing the begins of 2.wav and the corresponding fdkaac-lc-gap2-vbr5_2.m4a doesn't show such problems. The fdkaac-lc-gap2-vbr5_2.m4a is again a bit longer than 2.wav (which is of course explainable) but no bugs data seems to have been added at the end,... maybe because there was digital silence.

Long story short... that bogus audio+spike is quite a showstopper for anything not having digital silence in the end, especially gapless files.

Any ideas whether/how this could be fixed?

Cheers, Chris.

[calestyo]

Obviously this could also be a bug in the command line tool and not the library, so I've reported it there as well: nu774/fdkaac#19.

[mstorsjo]

The mp4/m4a container should (ideally) signal the exact number of samples to trim out at the end of the file, in order to get proper gapless playback. In this case, the spike is in the area that should be trimmed out, right? That would indicate that this is an issue with the command line tool (and how it writes the m4a container).

[calestyo]

Well it's a bit more than just the spike... just look at the image above, which include the original WAV. Everything what the WAV has less, is too much at the MP4... of course ignoring the length information in the container.

Well as I wrote I used fdkaac... but the upstream of that already closed the issue for unknown reasons, without actually fixing anything.

[mstorsjo]

Yes - it's not the spike, but the extra samples at the end.

At the end of any AAC stream, there are extra samples (due to only being able to encode full frames of 512/1024/2048 samples), unless the input data happened to be the exact correct number of samples. This info isn't in the AAC bitstream itself, but in the container. In most cases, people only use the encoder from the fdk-aac project and use some other library for writing the container file format. I think the fdk-aac project also contains code for writing container files although I haven't used that code myself.

So in this case, the first point of action would be to figure out what the fdkaac tool uses for writing the container file, and whether it signals the right number of samples to retain/strip. It's too bad if that issue was closed, that probably means someone else needs to debug that then.

[calestyo]

Well it's of course clear that there are extra samples due to the block based encoding, but I would have expected that the encoded audio is just longer, but everything extra is digital silence.

"people only use the encoder from the fdk-aac project" what do you mean here? aac-enc? But that doesn't seem to add such gapless information at all, at least neither mpv nor iPod played it gaplessly.

[mstorsjo]

No, the aac-enc tool doesn't do gapless at all - that tool is only a small example, not to be used for serious use. (That tool only writes ADTS streams which don't provide the extra info for gapless anyway.)

What I'm trying to say that the fdk-aac project contains a number of sub-libraries, one library for encoding the AAC bitstream, and libraries for reading and writing file formats. The AAC encoder library part is pretty widely used, but the libraries for reading and writing file formats aren't used by too many projects; most users only use the encoder part, but use other libraries for writing file formats (such as libavformat or something else). I do not know what library the fdkaac tool uses for writing the file formats.

Anyway, I read up on the issue report on the tool side now, and as far as I can see there, trimming of the trailing data should be signaled properly, so then the question is between your usecase (audacity and what other players you're using), and in what cases the tool claims that gapless works. (FWIW, I'm pretty sure that ffmpeg only trims away the extra samples at the start, but not at the end, at least that was the case not too long ago.)