GNOME Bugzilla – Bug 430085
[FAAC/FAAD] aac encoder output not interoperable with aac decoder on x86_64, possibly erroneous
Last modified: 2013-03-16 13:29:09 UTC
Please describe the problem: Songs imported from audio CDs using the default AAC seetings (Gstreamer pipeline: audio/x-raw-int,rate=44100,channels=2 ! faac ! ffmux_mp4) don't play back correctly. They constantly skip or jitter, and audio quality is ugly at best. Often, music is not even recognizable. Processor usage during playback is quite low, and free RAM is also not a prolem. The same audio files, uploaded onto an iPod, play back very fine, although reported track duration is incorrect (for example, 15'+ reported for a circa 4' song). Still the same audio files, when played inside the latest iTunes on Windows, also play back fine and report the correct track duration. Please, also note that other audio files, previously imported from audio CDs though the latest iTunes on Windows using the same hardware, play back just fine in all Gstreamer-based players that can't play back the files encoded through the Gstreamer AAC encoder. I think this might point to a problem in the encoder rather than the decoder, but feel free to ignore this as uninformed guess at best. I can attach or post a sample encoded track, which I think I could do under fair use. Please let me know if this is acceptable and if this could be helpful. Steps to reproduce: 1. Ensure you have the AAC encoder and decoder plugins 2. Insert non-drm-protected audio CD 3. Start Sound Juicer 4. From Edit | Preferences, select Output format CD Quality, AAC (MPEG 4 audio) 5. Import the CD 6. Play the songs in any Gstreamer-based player (Totem, Rhythmbox, Exaile!, ...) Actual results: Playback is ugly (constant jitters, noise, distorted or unrecognizable audio) Expected results: Playback is fine Does this happen every time? Always Other information:
You should probably use ... ! faac outputformat=1 without the ffmux_mp4. If you do want the mp4 muxer, you might need to feed it the AAC audio framed (not sure if we hava a parser for it though). Might be a bug in the muxer as well of course.
Thanks for your suggestion. The pipeline I used wasn't made by me -- it's the default Sound Juicer pipeline for AAC output, at least in the distro I use (Ubuntu Feisty). I tested as per your suggestion with outputformat=1 and no mp4 muxer. What I found is: 1) audio is better, but tracks keep "skipping" or jittering every 2-3 seconds... 2) the mp4 muxer is there for a reason; without it, output files have no tags (artist, album, title, etc.) I'd be happy to test with feeding AAC audio framed to the mp4 muxer, if you or someone else can please point me to directions as to how to setup the pipeline. I messed around with the bitrate parameter of faac, and I found that it dramatically affects the playability of the output file. In particular, lowering the bitrate makes everything worse (playback is slowed down and processor usage goes sky high -- on a double core Pentium D!), which seems counterintuitive to me... I might find some time to try more settings later.
I wanted to add aac support to SoundConverter, but I'm unable to get a valid mp4/m4a file, as described in this bug report. mp4/m4a files are detected by gstreamer as "audio/x-m4a", but with "faac ! ffmux_mp4" we generate "video/quicktime" I see that the mp4 header contains "ftypM4A" and the gstreamer encoded "ftypisom". After some tests, the file encoded with faac + ffmux_mp4 is unreadable (distorted, skipping...). With "faac outputformat=1", the result is better, but lacks a container, and the sound is still distorted. I also tested with the faac command line encoder, and the distorsion is also present, so the bad sound problem come from them. The container problem may need an option in ffmux_mp4 ? btw, you may want to add "profile=LOW" to faac to be sure it can be read anywhere see: http://www.audiocoding.com/modules/wiki/?id=LC
I have Fedora 7 here. The pipeline is as follows: audio/x-raw-int,rate=44100,channels=2 ! faac ! ffmux_mp4 The problem is that the files produced are a bit weird: they don't play on ipon (Nano 2nd generation), Winamp and iTunes, while they work in almost every linux app and QuickTime. Firing up khexedit shows the following difference between files encoded with iTunes: ftypeisom (juicer) vs ftypM4A (iTunes) are the first bytes. Quality seems to be fine in both cases.
I did some test and here is what I've found. faac, when used with -w option (container), produces ipod-digestible files, albeit gnome still changes the icon to video upon hovering over them. The header roughly is: ftypmp42 mp42isom e .mdat. At the same time, gstreamer, when invoked by soundjuicer, throws out files which ipod doesn't digest, also changing to video icon upon hovering. They have the following header: ftypeisom mp41 free i[amdat It looks like both faac and gstreamer do something wrong, but faac gives less broken files.
It seems that ipod issue is unrelated. faac encodes to LC AAC by default, while gstreamer seems to prefer MAIN AAC. The latter seems to be unsupported by my ipod.
I opened a separate bug concerning LC AAC (#498617). I examined the case futher, using file command and MIME types reported by nautilus: gstreamer-created aac: video/mp4; ISO Media, MPEG v4 system, version 1 faac-created aac: video/mp4; ISO Media, MPEG v4 system, version 2 iTunes-created aac: audio/mp4; ISO Media, MPEG v4 system, iTunes AAC-LC
I can't reproduce bad/choppy playback with default sound-juicer settings (Gstreamer pipeline: audio/x-raw-int,rate=44100,channels=2 ! faac ! ffmux_mp4) I neither see video icons for encoded files. This is on Ubuntu 8.04 gstreamer 0.10.18 Can we close this, Tommaso?
I just run a test on my box (Ubuntu 8.04 too, which is to say gstreamer 0.10.18, gstreamer-plugins-bad 0.10.6-5, gstreamer-plugins-bad-multiverse 0.10.6-1). Sound quality is better, but sound is too trembling and at times there's a lot of reverb on GStreamer-based players. Sound quality is better on my iPod (some segments almost flawless) and track duration is now reported correctly. Anyway, I'm sorry to report that quality on GStreamer-based players is too low to be useful. If you're having good results, I guess this depends on the input, so I'll try again later with something less demanding and will let you know. For classical music, the encoder is still not there... :-( Unless, the difference we hear depends on the platform, I'm on AMD64.
Now that you mention ... x86_64 could certainly be the reason. Maybe you can try to install the x86_32 packages temporarily? I remember we once had choppy audio playback in conjunction with alsa and/or mp3. This was due to wrong internal gstreamer time stamping. well. I use x86_32 and audio quality is fine for me. I just tested with Vocal Jazz songs, encoded at 192 kbps, Sennheiser headphones. Maybe we can exchange encoded song files and hence test whether encoding or decoding is the culprit for you. Feel free to find my email address by clicking on my name.
We've exchanged encoded audio samples and I could not reproduce choppy playback, neither Tommaso. Altough his sample sounds a bit strange to me ... anyways, we concluded that the matter of this report is no longer valid. Tommaso feel free to open new reports about other issues, like the 'trembling' audio.
Actually I am on AMD64 now and encoded to AAC using gstreamer-plugins-bad and the faac plugin. I noticed slightly choppy and somehow distorted playback. I have not tested playback on my iPod nor any other different playback yet. gstreamer0.10-plugins-bad 0.10.6-1ubuntu1
I can reproduce this on AMD64
Christian: it sounds like the bug is now something else than what's mentioned in the summary - could you update the summary please? > I can reproduce this on AMD64 Great, but how? If we can also reproduce this, maybe we can fix it ..
Ping...?
I hope I can look into this again this week
If I remember correctly, the way was to use sound-juicer and the default AAC pipeline audio/x-raw-int,rate=44100,channels=2 ! faac ! ffmux_mp4 for ripping and then play back using any gstreamer app. YAP, I can still reproduce also with the pipeline audio/x-raw-int,rate=44100,channels=2 ! faac outputformat=1 the results sound identical to me - there are two problems I can hear: 1. I suspect the replay gain is not working fine. For instance on medium and strong acustic guitar strokes the subjective volume drops significantly and then increases again afterwards. That explanation is just guess. 2. there are tiny (mute) gaps when playing ocurring occasionally. You can hear it best when there is a tone of constant frequency sounding for some time. It is not easy to notice. nazgul@rivendell:~$ dpkg -la|grep gstreamer ii gstreamer-tools 0.10.22-1 Tools for use with GStreamer ii gstreamer0.10-alsa 0.10.22-5 GStreamer plugin for ALSA ii gstreamer0.10-esd 0.10.14-1ubuntu0.1 GStreamer plugin for ESD ii gstreamer0.10-ffmpeg 0.10.6.2-1ubuntu2 FFmpeg plugin for GStreamer ii gstreamer0.10-fluendo-mp3 0.10.7.debian-1 Fluendo mp3 decoder GStreamer plugin ii gstreamer0.10-gnomevfs 0.10.22-5 GStreamer plugin for GnomeVFS ii gstreamer0.10-plugins-bad 0.10.11-2ubuntu1 GStreamer plugins from the "bad" set ii gstreamer0.10-plugins-bad-multiverse 0.10.11-0ubuntu1 GStreamer plugins from the "bad" set (Multiv ii gstreamer0.10-plugins-base 0.10.22-5 GStreamer plugins from the "base" set ii gstreamer0.10-plugins-base-apps 0.10.22-5 GStreamer helper programs from the "base" se ii gstreamer0.10-plugins-base-dbg 0.10.22-5 GStreamer plugins from the "base" set ii gstreamer0.10-plugins-good 0.10.14-1ubuntu0.1 GStreamer plugins from the "good" set ii gstreamer0.10-plugins-good-dbg 0.10.14-1ubuntu0.1 GStreamer plugins from the "good" set ii gstreamer0.10-plugins-ugly 0.10.10.2-1build1 GStreamer plugins from the "ugly" set ii gstreamer0.10-plugins-ugly-dbg 0.10.10.2-1build1 GStreamer plugins from the "ugly" set ii gstreamer0.10-plugins-ugly-multiverse 0.10.7-2 GStreamer plugins from the "ugly" set (Multi ii gstreamer0.10-pulseaudio 0.10.14-1ubuntu0.1 GStreamer plugin for PulseAudio ii gstreamer0.10-schroedinger 1.0.5-1 GStreamer plugin for encoding/decoding of Di ii gstreamer0.10-tools 0.10.22-1 Tools for use with GStreamer ii gstreamer0.10-x 0.10.22-5 GStreamer plugins for X11 and Pango ii libgstreamer-plugins-base0.10-0 0.10.22-5 GStreamer libraries from the "base" set ii libgstreamer-plugins-base0.10-dev 0.10.22-5 GStreamer development files for libraries fr ii libgstreamer0.10-0 0.10.22-1 Core GStreamer libraries and elements ii libgstreamer0.10-0-dbg 0.10.22-1 Core GStreamer libraries and elements ii libgstreamer0.10-dev 0.10.22-1 GStreamer core development files ii totem-gstreamer 2.26.1-0ubuntu5 A simple media player for the GNOME desktop
Let's close this, I don't see any actionable info in here, I don't think it's useful to keep it open. If there are still issues (which I'm not aware of - I think we've fixed most of the FAAD/FAAC API/ABI mess a long time ago) someone will file a new bug :)