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 o
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.
--
You received this bug notifi
** Summary changed:
- ffmpeg generates mono ALAC .m4a sound files which play double speed
+ ffmpeg generates mono ALAC .m4a sound files which play double speed in totem
(but play fine with ffplay and alac-decoder)
** Package changed: ffmpeg (Ubuntu) => libav (Ubuntu)
** Changed in: libav (Ubun
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 commen
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 plea
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.
--
ffmpeg gene
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 enc
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.
--
ffmpeg generates mono ALAC .m4a sound files which play double speed
https://bugs.launchpad.net/bugs/6619
If ffplay and co decode properly, why not reporting it to totem
upstream?
jimav, why have you reassigned to the ffmpeg package?
--
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 membe
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
** Changed in: ffmpeg (Ubuntu)
Status: New => Confirmed
--
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
** Package changed: gstreamer0.10 (Ubuntu) => ffmpeg (Ubuntu)
--
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 m
12 matches
Mail list logo
