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 library and not the command line tool, so I've reported it there as well: mstorsjo/fdk-aac#35.

[nu774]

Well, How did you decode them?

Like many lossy codecs, AAC always has some amount of codec delay and padding. Length of delay / padding are saved in the MP4 container. To be gapless, these delay/padding samples has to be trimmed on the decoder/player side. Unfortunately, not every decoder/player supports it, and you need to find one that properly supports gapless decoding of AAC.

[calestyo]

Audacity,.. not sure what that uses,.. probably ffmpeg?

Well but the encoding in blocks shouldn't mean that there cannot be any silence where the source has ended, right? But what's produced by libfdk-aac/fdkaac has no silence, but adds more data which seems to be like a copy of the previous block.

At least the ipod is sure to be able to playback AACs gaplessly and mpv should do so as well (tell me which player you'd expect to support gapless playback),... so there is definitely something wrong with the produced files,... which is why I cannot quite understand why you close the bug after no further discussion and with no solution being found. Or is your fork of fdkaac no longer maintained?

[nu774]

But what's produced by libfdk-aac/fdkaac has no silence, but adds more data which seems to be like a copy of the previous block.

That's because fdkaac extrapolates the beginning and ending in order to avoid glitches between the song. Those extrapolated padding generated by fdkaac is going to be removed on decoder side if decoder supports proper gapless playback. So, it is not what you have to care. See https://github.com/nu774/qaac/wiki/Encoder-configuration (Chapter named "Smart padding" at the bottom of the page) for more details.

At least the ipod is sure to be able to playback AACs gaplessly and mpv should do so as well (tell me which player you'd expect to support gapless playback),...

Since mpv is based on ffmpeg, I don't think it's gapless. I think ipods should be fine (at least not old ones), but it might need --gapless-mode=0 (iTunSMPB). Basically speaking, --gapless-mode is 0 by default, and you shouldn't be touching this option.

Finally, I closed your issue because I KNOW it's not an issue on fdkaac side, and I don't want to waste my time on it.

[calestyo]

Well as you say, ipods should do it right, mpv can at least play back MP3 and Vorbis gaplessly, and AFAIK AAC/MP4 as well.

As I further mentioned, I've also tried with -G 0, with the same results.

So you say it's not an issue in your front end, and the library's upstream says it is an error in fdk-aac ... yet it's there... o.O

[mstorsjo]

I'm not strictly saying it's an issue with the fdkaac tool, but I'm saying that it's not an issue with the fdk-aac library at least. And according to the comments here, it should be working fine as long as the player interprets the data properly - right?

[calestyo]

Well at least somewhere is some problem (my intention is not to "blame" anyone... just to get things fixed)... any my knowledge in digital audio encoding / AAC is too little as that I could really debug it.

All I can say is that the thing happens,.. and that at least the iPod should be expected to play back gaplessly. mpv does so for MP3 and I'd assume it would do so for AAC/MP4 as well, but I don't know for sure, which is why I make a small ticket over at mpv to get their attention.

Anyway,... is that really expected, that the encoded file isn't just longer (due to the padding) than the WAV, but also has anything else but digital silence in it?

[nu774]

Well, try the following to isolate the problem and see if the issue is on fdkaac side or your player/decoder (I KNOW that it's not an issue of fdkaac and I'm really uninterested, but these steps might be required to make you convinced).

• Try other AAC encoders (such as neroaacenc, iTunes, WinAmp)
• Try decoders known to support gapless decoding of LC-AAC at least (HE-AAC is more problematic). Such as neroaacdec, foobar2000, rockbox, poweramp, and iTunes.

As far as I know, ffmpeg only trims the beginning of AAC but not the ending. libav(fork of ffmpeg) doesn't do trimming at all. Therefore, quite many players relying on them (including mpv) doesn't support gapless playback of AAC.

And also you can try trimming decoded result yourself by looking at iTunSMPB tag. It is explained at: http://sourceforge.net/p/mediainfo/feature-requests/398/