#2244 closed defect (fixed)
ffmpeg creates invalid odd-byte length wav files
Reported by: | dave rice | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | git-master | Keywords: | wav |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description
Summary of the bug:
When I copy the audio data with ffmpeg from wav to wav and the source has an odd-byte-length data chunk then the resulting file is invalid because the output file is missing the required padding byte. In the command below this results in a 144,485 byte wav file (odd length RIFF chunks are not allowed). I can manually make the output valid by appending a padding byte to the end.
I'm attaching a sample source file: a valid wav file with mono 24 bit audio. The file has an odd-byte data length (this happens about half the time when recording 24 bit mono).
How to reproduce:
ffmpeg -i oddbytedatalength.wav -c copy copied.wav ffmpeg version 1.1.git Copyright (c) 2000-2013 the FFmpeg developers built on Feb 6 2013 22:00:51 with Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn) configuration: --prefix=/usr/local/Cellar/ffmpeg/HEAD --enable-shared --enable-pthreads --enable-gpl --enable-version3 --enable-nonfree --enable-hardcoded-tables --enable-avresample --cc=cc --host-cflags= --host-ldflags= --enable-libx264 --enable-libfaac --enable-libmp3lame --enable-libxvid --enable-ffplay --enable-libopenjpeg --extra-cflags='-I/usr/local/Cellar/openjpeg/1.5.1/include/openjpeg-1.5 ' libavutil 52. 17.101 / 52. 17.101 libavcodec 54. 91.101 / 54. 91.101 libavformat 54. 61.104 / 54. 61.104 libavdevice 54. 3.103 / 54. 3.103 libavfilter 3. 35.101 / 3. 35.101 libswscale 2. 2.100 / 2. 2.100 libswresample 0. 17.102 / 0. 17.102 libpostproc 52. 2.100 / 52. 2.100 Input #0, wav, from 'oddbytedatalength.wav': Metadata: encoder : Lavf54.61.104 Duration: 00:00:01.00, bitrate: 1153 kb/s Stream #0:0: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 48000 Hz, mono, s32, 1152 kb/s Output #0, wav, to 'copied.wav': Metadata: ISFT : Lavf54.61.104 Stream #0:0: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 48000 Hz, mono, 1152 kb/s Stream mapping: Stream #0:0 -> #0:0 (copy) Press [q] to stop, [?] for help size= 141kB time=00:00:01.00 bitrate=1152.8kbits/s video:0kB audio:141kB subtitle:0 global headers:0kB muxing overhead 0.070645%
Attachments (3)
Change History (6)
by , 12 years ago
Attachment: | oddbytedatalength.wav added |
---|
by , 12 years ago
Attachment: | copied.wav added |
---|
invalid output from -c copy with ffmpeg, the output is odd byte length but without padding byte
comment:2 by , 12 years ago
Interestingly, FFmpeg (still) claims that the original file is invalid:
$ ffmpeg -i oddbytedatalength.wav -f null - ffmpeg version N-49708-ga92816c Copyright (c) 2000-2013 the FFmpeg developers built on Feb 9 2013 01:34:27 with gcc 4.7 (SUSE Linux) configuration: --enable-gpl --disable-indev=jack libavutil 52. 17.101 / 52. 17.101 libavcodec 54. 91.102 / 54. 91.102 libavformat 54. 61.104 / 54. 61.104 libavdevice 54. 3.103 / 54. 3.103 libavfilter 3. 35.101 / 3. 35.101 libswscale 2. 2.100 / 2. 2.100 libswresample 0. 17.102 / 0. 17.102 libpostproc 52. 2.100 / 52. 2.100 Input #0, wav, from 'oddbytedatalength.wav': Metadata: encoder : Lavf54.61.104 Duration: 00:00:01.00, bitrate: 1153 kb/s Stream #0:0: Audio: pcm_s24le ([1][0][0][0] / 0x0001), 48000 Hz, mono, s32, 1152 kb/s Output #0, null, to 'pipe:': Metadata: encoder : Lavf54.61.104 Stream #0:0: Audio: pcm_s16le, 48000 Hz, mono, s16, 768 kb/s Stream mapping: Stream #0:0 -> #0:0 (pcm_s24le -> pcm_s16le) Press [q] to stop, [?] for help Multiple frames in a packet from stream 0 [pcm_s24le @ 0x2c713e0] Invalid PCM packet, data has size 2 but at least a size of 3 was expected Error while decoding stream #0:0: Invalid data found when processing input size=N/A time=00:00:01.00 bitrate=N/A video:0kB audio:94kB subtitle:0 global headers:0kB muxing overhead -100.022856%
comment:3 by , 12 years ago
@cehoyos. I see the invalid error is a fault with my sample and that ffmpeg's warning is correct. I was replicating a odd-byte-length 24 bit mono file with a hex editor rather than send the 2 gig original and I made an error. I'm going to upload a proper odd-byte-length data chunk wav if anyone is someday interested. Thanks for the fix.
by , 12 years ago
Attachment: | oddbytedatalength_fixed.wav added |
---|
valid version of oddbytedatalength.wav
source file, a valid wav file with odd-byte-length data chunk and required padding byte