GNOME Bugzilla – Bug 498617
RFE: AAC profile should encode to LC-AAC by default
Last modified: 2008-12-14 20:02:18 UTC
Currently, the files are encoded to AAC Main, which is less compatible, e.g. with iPods. There are other funky issues related to AAC (bug #430085), but they seem to be unrelated. Regards, Julian
Re-assigning to gnome-media.
I first want to see an actually working pipeline. I'm not going from broken to [more|less] broken.
Well, I'm not sure if there is anything wrong with the pipeline. I did some experiments regarding bug #430085 and in all cases the files did contain perfectly fine sound. This includes default sound-juicer AAC profile. The only problem I have observed is that the container is interpreted as a video for some reason. This also happens with command-line faac, but in that case the file header is a bit different. I have reported this issue upstream (SourceForge issue #1835326). I have not tried mpeg4ip (libmp4v2 comes from it) 1.6.1 yet, but since Noa Resare's script does not work with this version, there is not much left I can do.
*** Bug 499069 has been marked as a duplicate of this bug. ***
Julian, did you found a solution to produce valid AAC files? This bug looks like a gstreamer or faac bug. Did you try to tweak faac element options ? The link to your bug report is: http://sourceforge.net/tracker/index.php?func=detail&aid=1835326&group_id=704&atid=100704 The current profile pipeline is: audio/x-raw-int,rate=44100,channels=2 ! faac ! ffmux_mp4 (the duplicated bug is invalid dup) Reassinging to gstreamer
Well, I did not fiddle with the options a lot, but as far as I remember, the files encoded with faac work on ipod. The only issue is the broken header, which seems to be caused by faac - the comparison given in comment #7 of bug #430085 shows that while the headers differ a bit, both plain faac and gstreamer throw out video/mp4 files for some reason. As pointed in the Sourceforge report, probably due to the presence of mdat field. Since faac devs do not seem to be very responsive, I would just ignore the broken header issue, and tweak the pipeline to use LC-AAC. The container will be hopefully fixed later.
faac devs closed the bug as invalid: "The bug is in the application you use for playback. It assumes a file with audio only will have "M4A " in the file type description, and assumes files without that to have video. This is a false assumption. The player should check what kind of track types are in the file to draw any conclusions"
Julian, is there still something we can do? is the current pipeline ok? thanks
Yes, you can change the default AAC pipeline to encode to LC-AAC. Files encoded with the current one do not work on my iPod (nano 2nd generation).
Julian, I don't have an ipod, and for some reasons, faac is not in Debian. Can you give the pipeline you use? thanks
Well, I never tried to obtain an LC AAC file with gstreamer, but I could possibly look into it.
According to docs, profile=2 should do the trick. I'll test if it really works.
audio/x-raw-int,rate=44100,channels=2 ! faac profile=2 ! ffmux_mp4 seems to work.
thanks, fixed in .r4098