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. -- ffmpeg generates mono ALAC .m4a sound files which play double speed https://bugs.launchpad.net/bugs/661922 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
