GNOME Bugzilla – Bug 599877
AAC (.m4a) files skip when played in Rhythmbox
Last modified: 2012-02-18 13:56:43 UTC
I own the Homestuck Vol. 1 soundtrack (http://www.mspaintadventures.com) in AAC format (output of _file_ is "ISO Media, MPEG v4 system, iTunes AAC-LC"). I downloaded the necessary bits of gstreamer to play these, but when I do there is momentary skipping approximately every five seconds. It doesn't matter whether it's in Rhythmbox or via Nautilus' preview, I get the same skipping. The files played just fine in Windows under foobar2000.
Could you make a sample file available please, or point us towards a download link?
Oh, sorry. Here: http://ketsuban.cleverpun.com/01 Showtime (Piano Refrain).m4a
Easily reproducable: fwiw ffdec_alac outputs one sample per input buffer, always with the same timestamp but a different duration: (identity0:sink)i (6178 bytes, timestamp: 0:00:00.000000000, duration: 0:00:00.085333333 (identity1:sink)i (16384 bytes, timestamp: 0:00:00.000000000, duration: 0:00:00.092879818 (identity0:sink)i (4995 bytes, timestamp: 0:00:00.085333333, duration: 0:00:00.085333333 (identity1:sink)i (16384 bytes, timestamp: 0:00:00.085333333, duration: 0:00:00.092879818 (identity0:sink)i (4372 bytes, timestamp: 0:00:00.170666666, duration: 0:00:00.085333334 (identity1:sink)i (16384 bytes, timestamp: 0:00:00.170666666, duration: 0:00:00.092879818
When running "filesrc ! qtdemux ! ffdec_alac ! fakesink -v" I get: /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < (16384 bytes, timestamp: 0:00:00.000000000, duration: 0:00:00.092879818, offset: -1, offset_end: -1, flags: 32) 0x1c202b0" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < (16384 bytes, timestamp: 0:00:00.085333333, duration: 0:00:00.092879818, offset: -1, offset_end: -1, flags: 0) 0x1c201b0" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < (16384 bytes, timestamp: 0:00:00.170666666, duration: 0:00:00.092879818, offset: -1, offset_end: -1, flags: 0) 0x1c200b0" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < (16384 bytes, timestamp: 0:00:00.256000000, duration: 0:00:00.092879818, offset: -1, offset_end: -1, flags: 0) 0x19e9e80" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < (16384 bytes, timestamp: 0:00:00.341333333, duration: 0:00:00.092879818, offset: -1, offset_end: -1, flags: 0) 0x1c20030" /GstPipeline:pipeline0/GstFakeSink:fakesink0: last-message = "chain ******* < (16384 bytes, timestamp: 0:00:00.426666666, duration: 0:00:00.092879818, offset: -1, offset_end: -1, flags: 0) 0x1c20130" Timestamps are increasing and duration is fixed.
something is weird with the samplerate. qtdemux says it 48000 but ffdec then changes it to 44100.
This file is broken. qtdemux has 44100 as the samplerate (this is correct) but then calculates timestamps as if it's a 48000 Hz file. This screws up the timestamping. vlc and xine also skip badly while trying to keep up with the timestamps. mplayer seems to ignore timestamps and plays this ok. There is not much we can do about that because alac does not have a fixed number of samples in a frame. This means we can't estimate the samplerate and correct. We could disable timestamps in playbin2 when dealing with audio-only files but that seems like the wrong thing to do.
Closing as CANTFIX/WONTFIX then..