GNOME Bugzilla – Bug 629291
wav files have huge chunk sizes
Last modified: 2010-09-10 18:23:13 UTC
wavenc name=enc created files all have a chunk size of 0x7fff0024 (you can subtract 4 if you feel like it) which is of the order of 2 GB, regardless on how small the file is. (The chunk size is encoded in the 4 bytes following the initial "RIFF" string.) These files then get rejected by "other" programs as containing invalid arguments. (The chunk size in the data section is also similarly huge.) The way I reproduced this: Ubuntu lucid 10.04.1, linux 2.6.32-25-generic x86_64 gnome-sound-recorder 2.30.0 Record as: Voice, Lossless (.wav type) gconftool -a /system/gstreamer/0.10/audio/profiles/voicelossless tells you that pipeline = audio/x-raw-int,rate=22050,channels=1 ! wavenc name=enc Example file: hexdump: 00000000 52 49 46 46 24 00 ff 7f 57 41 56 45 66 6d 74 20 |RIFF$...WAVEfmt | 00000010 10 00 00 00 01 00 01 00 22 56 00 00 88 58 01 00 |........"V...X..| 00000020 04 00 20 00 64 61 74 61 00 00 ff 7f 00 00 00 00 |.. .data........| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 |................| 00000070 00 00 ff ff 00 00 02 00 00 00 fe ff 00 00 02 00 |................| annotated: 00000000 52 49 46 46 "RIFF" 24 00 ff 7f 0x7fff0024 - 4 = 2147418144 57 41 56 45 "WAVE" 66 6d 74 20 "fmt " 00000010 10 00 00 00 chunk size = 16 01 00 format = PCM 01 00 channels = 1 22 56 00 00 sampling rate = 22050 88 58 01 00 data rate = 88200 00000020 04 00 4 byte data block 20 00 32 bits per sample end of fmt chunk 64 61 74 61 "data" 00 00 ff 7f 0x7fff00 = 2147418112 00 00 00 00 |.. .data........| 00000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................| * 00000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 |................| 00000070 00 00 ff ff 00 00 02 00 00 00 fe ff 00 00 02 00 |................|
How did you create these files? Something like the following produces a correct chunk size: gst-launch-0.10 audiotestsrc num-buffers=1000 ! wavenc ! filesink location=test.wav
Note that wavenc first writes a chunk size of 0x7FFF0000 and only writes the real value after end of stream. If the seeking back to position 0 fails or the pipeline is stopped without EOS you'll get a wrong value there of course.
I produced them as per paragraph 2 above... run gnome-sound-recorder 2.30.0, with record as Voice, Lossless. Click record, stop, save the wav file. hexdump wav file and observe large chunk value. I can confirm that your audiotestsrc way of creating a wav gives the correct chunk size. Your comment 2 suggests that clicking the stop icon in sound recorder doesn't elegantly stop the stream?
Maybe this is related to Bug 456634 ... Will check later...
Yes, that's bug #456634. When stopping the pipeline it should send an EOS event to the pipeline and then wait until the EOS message is emitted. *** This bug has been marked as a duplicate of bug 456634 ***