ffmpeg generates mono ALAC .m4a sound files which play double speed in totem (but play fine with ffplay and alac-decoder)

[jimav]

(description edited)

ALAC (Apple Lossless Audeo Codec) sound files created with "ffmpeg -acodec alac" play
at double speed using totem, if the original input .wav file was monophonic.
The problem does not occur with stereo files.

The resulting mono .m4a file plays wrong on an iPOD classic, and on Linux using totem.
The same mono .m4a decodes on linux using alac-decoder to produce a *stereo* .wav file which plays at normal speed (I'm guessing that whatever the problem is with the mono ALAC .m4a file is "fixed" by duplicating the mono track).

Since the iPOD matches totem's behavior, it is extremely likely that ffmpeg needs to be changed to generate mono ALAC files which play correctly (OTOH, Apple might have a bug in its decoders with mono files).

Note: ALAC is not documented by Apple, so the only standards are Apple's close-source implementations.

I will attach a second demo archive. This time there are two small .wav files, one stereo and the other mono. The mono file was created from the stereo file using Audacity's Tracks->Stereo Track to Mono feature.

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: libgstreamer0.10-0 0.10.30-1build2
ProcVersionSignature: Ubuntu 2.6.35-22.34-generic 2.6.35.4
Uname: Linux 2.6.35-22-generic x86_64
Architecture: amd64
Date: Sat Oct 16 14:48:38 2010
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release Candidate amd64 (20100928)
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: gstreamer0.10

[llogan (loul)]

ALAC output from FFmpeg SVN-r25628 on Maverick is also distorted in Maverick's Totem. Totem 2.32.0/gstreamer0.10-ffmpeg 0.10.10 in Arch Linux x86_64 also has distorted decoding from the same output. FFplay from Maverick repo and FFplay SVN decode the file properly.

Consider reporting it upstream to FFmpeg (although they may blame totem, gstreamer, and/or iPod).

[Reinhard Tartler (siretart)]

If ffplay and co decode properly, why not reporting it to totem upstream?

jimav, why have you reassigned to the ffmpeg package?

[llogan (loul)]

I mentioned forwarding to FFmpeg only because the iPod had issues with the ALAC output as well, but that may be a separate issue and it may be more suitable to report this to Totem instead.

[jimav (james-avera)]

To answer Reinhard's qustion (why I reassigned to ffmpeg): Initially it seemed like a playback (decoding) bug with totem, since the same files "work fine" using alac-decoder. So I filed the bug against gstreamer (totem's decoder). But later it seemed more likely that mono ALAC files were encoded incorrectly and that it was not a playback (decoding) bug after all; so I changed the package to ffmpeg, which is the program I used to encode the mono ALAC files.

The evidence pointing to an encoding bug is:
1) iPODs also play the files double-speed. If Apple's decoder is correct [big if], then the encoder is wrong.
2) alac-decoder turns out to not "work fine" after all, but incorrectly converts mono ALAC to stereo WAV files. Stereo files, suspiciously, consume twice as many samples per second during playback, so this might be a compensating bug which, if fixed, would cause alac-decoder to also play these files at double speed (just speculating here).

I think this needs a look by someone who knows the details of ALAC and WAV (i.e. someone who reverse-engineered ALAC...) Such a person should be able to examine the mono ALAC files and see whether or not they look correct.

[jimav (james-avera)]

I sent a message to the author of alac-decoder (David Hammerton at craz.net) asking if he would comment on this bug. He reverse-engineered ALAC and likely has the needed expertise.

Incidentally, his latest release of alac-decoder behaves the same as the older version in Ubuntu.

[Reinhard Tartler (siretart)]

thanks for the explanation.

I don't think that I have an ipod around here to test, but this is
indeed an indication for an faulty alac encoder.

Next steps: we need to know if this still happens with ffmpeg trunk's
alac encoder and if yes, then forward this upstream.

Just to be sure, can you please share your ffmpeg command line that you
used to create mono alac files?

--
Gruesse/greetings,
Reinhard Tartler, KeyID 945348A4

[jimav (james-avera)]

Summary:

ffmpeg -i mono.wav -acodec alac alac_mono.m4a # output is alac_mono.m4a
totem alac_mono.m4a # plays double speed

alac-decoder -f decoded.wav alac_mono.m4a # output is decoded.wav, which is STEREO (a bug)
totem decoded.wav # plays normally (in stereo).

(The attachment to comment#2 contains sample files and a demo script with these commands.)

Note: "mono.wav" is a 1-track (monophonic) WAV file, e.g., from a field recording. Another way to create a mono .wav file is to rip a commercial CD, and convert one of the tracks to mono using Audacity's "Tracks->Stereo Track to Mono" feature.

[Justin Ruggles (justin-ruggles)]

I can confirm that this issue still exists in Libav master branch. I was able to reproduce with Totem on Maverick. Interestingly, if you output to mov instead of m4a then Totem plays it correctly. Both file formats play correctly on QuickTime Player for Windows.

[Justin Ruggles (justin-ruggles)]

I might be wrong, but from what I can tell, gstreamer does not parse the alac atom, but relies only on the sound sample description to get audio properties. The problem with this is that, in mp4, channels in the version 0 sound sample description is reserved as 2 no matter what the actual number of channels is. The reader must parse the alac atom in order to get the actual number of channels.

I'll test this on iPod as soon as I get a chance to see if I can reproduce the issue there.