New submission from LRN <[EMAIL PROTECTED]>: FFmpeg truncates and pads audio.
How to reproduce: take any encoded audio file and decode it to PCM WAV with reference decoder and with FFmpeg, then compare the results. WAV, produced by FFmpeg, may be shorter or longer and/or may have additional silence. How much shorter/longer or how much silence - depends on codec and samplerate, but the difference never exceeded 300ms for all codecs i've tested. If reference decoder is not available, it is possible to test in a bit more complex way: take uncompressed PCM WAV, encode it with FFmpeg, then decode back to PCM. But you'll need a wave audio editor (i used Audacity), to see the difference, and you'll have to account for possible encoder bugs and test with reference encoder too. Here's a few decoding tests. All ms values are taken by sight, measurement inaccuracy may be up to 10 samples, i think. "Foo/Bar" means "File was decoed by Foo using Bar library". "Foo + Bar/Baz" means "File was decoded by Foo, then by Bar using Baz library". FLAC (encoded with FFmpeg): FFmpeg.exe truncated 220ms of audio at the end on decoding. flac.exe + Audacity/libsndfile decoded normally. MP3 (encoded with FFmpeg/libmp3lame, -ab 256k): FFmpeg.exe slienced last 11ms of audio on decoding. Also added 15ms of silence on top of that. Audacity/libmad truncated audio at the beginning (!) and at the end (same 11ms at the end). Seems to be bug in libmad or libmp3lame. File is probably truncated at encoding time. Vorbis (encoded with FFmpeg, -aq 80): FFmpeg truncated 23ms of audio at the end Audacity/libvorbis truncated 23ms of audio at the end, also inverted it (???). Looks like the file was truncated at encoding time. Vorbis (encoded with Audacity/libvorbis, quality = 8): FFmpeg/libfaad2 added 13ms of silence at the end and inverted the track. Audacity/libvorbis decoded normally. AAC (encoded with FFmpeg/libfaac, -ab 256k): FFmpeg truncated 115ms of audio at the end. NeroAacDec + Audacity/libsndfile added 23ms of silence at the beginning and truncated 115 ms of audio at the end. Looks like the file was truncated at encoding time. AAC (encoded with NeroAacEnc, -br 262144): FFmpeg/libfaad2 added 36ms of silence at the beginning and added 10ms of silence at the end. No truncation. NeroAacDec + Audacity/libsndfile decoded normally. As you can see, there's no clear pattern - each codec gives different results. My advice: make sure FLAC decodes properly. There is no padding at the beginning for FLAC, so you can just count the number of samples in original PCM-WAV and resulting PCM-WAV->FLAC->PCM-WAV file to make the testing process automatic. I think the bug is in avcodec, but i may be wrong and it's just the FFmpeg issue. merbz says it's because most codecs align audio to a block size, and that the only fix is to feed a codec with silence to make sure the last block reaches required size. But i doubt this is the only issue. Not sure where padding comes from... Anyway, my wish is simple: original and transcoded (twice) waves should match (taking into account possible compression losses). Additional data for other codecs(PCM-WAV->*->PCM-WAV, FFmpeg only): ac3: ~257 padded samples, ~761 samples truncated at the end adpcm_ima: 0 padded samples, ~139 samples truncated at the end adpcm_ms: 0 padded samples, ~316 samples truncated at the end adpcm_yamaha: 0 padded samples, ~2040 samples truncated at the end libamr-nb: ~226 padded samples, ~1153 samples truncated at the end libamr-nb: ~263 padded samples, ~1167 samples truncated at the end libgsm: 0 padded samples, garbage after 104073-th sample mp2: ~481 padded samples, ~986 samples truncated at the end wmav1: ~2052 padded samples, ~4093 samples truncated at the end wmav2: ~2052 padded samples, ~4093 samples truncated at the end sonic: segfault sonicls: 0 padded samples, garbage after 2047-th sample If you want the audio file i used for tests - look at issue491. ---------- messages: 2302 nosy: LRN priority: normal status: new substatus: new title: FFmpeg truncates and pads audio topic: avcodec type: bug ______________________________________________________ FFmpeg issue tracker <[EMAIL PROTECTED]> <https://roundup.mplayerhq.hu/roundup/ffmpeg/issue498> ______________________________________________________
