Comment 39 for bug 602934

(In reply to comment #26)
> I have been unable to pin down why M4A imports are silenced. Actually, I no
> longer see this, so if y'all can attach a file to this bug that consistently
> imports as silence that'd be great.
For me, the same file will sometimes import as silence and sometimes not. The
silencing was happening every time after applying the 0-6-1 support and import
crash patches. After reboot, it hardly happens, but sometimes does.

> Heck, if you have a mono file that imports as stereo, please attach that
> as well.
You gonna love this. I generated a default 30s chirp in Audacity on Win 7 and
Audacity on Ubuntu. I exported with (external program) and default

 ffmpeg -i - %f

naming the file as chirp.m4a. Win FFmpeg is 0.5, Ubuntu FFmpeg is the Ubuntu
package. The ffmpeg output says it wrote a mono file. The chirp.m4a exported on
Ubuntu imports as mono into Audacity on Ubuntu, and most apps see it as mono
e.g MediaInfo, but VLC imagines it is stereo.

If I import that chirp.m4a exported on Ubuntu into Audacity on Win 7, it
imports as stereo. dBPowerAmp and MediaInfo (slightly old version) see it as
stereo. QT and iTunes see it as mono.

If I drag the chirp.m4a produced on Windows 7 into Audacity on Windows, it
imports as stereo.

If I drag the chirp.m4a produced on Windows 7 into Audacity on Ubuntu, it
imports as mono, and Ubuntu apps see it as mono (or stereo for VLC) as before.

I think you will be able to repro it on Windows (and I assume on FFmpeg 0.6.1
too, but I have not tried with 0.6.1 yet). What happens on Mac?

> One thing that I did discover is that on 2010-05-14, the native aac encoder
> was updated and this caused a tremendous degradation in export quality. I do
> not believe this to be an Audacity issue since the ffmpeg command produces
> the same results.

Agreed, but would still have to be release noted because we will be blamed
otherwise.

Or could/should we disable Audacity support for the native aac encoder via
normal "M4A files" export? I think it would send an appropriate message.

> Another thing is that exporting a 10 minute chirp on my system consistently
> takes 22 seconds prior to the ffmpeg changes on 2010-04-02. After that date,
> exporting the same chirp consistently takes 35 seconds. Again, I do not
> believe this to be an Audacity problem since the ffmpeg command produces
> nearly the same time difference as Audacity.
That is a much less significant difference than that implied by the "3 - 4
times slower" than Audacity export to other formats. Can you test on your
system:

* How much less than 35 seconds does that file take to export via LAME at the
command-line?

* How much slower is Audacity GUI export to AAC (using FFmpeg 0.6.1) than to
other formats?

I wonder (even if it is an FFmpeg issue) if Audacity is making it worse?

FWIW I tested M4A encoding in FFmpeg 0.5 versus 0.6.1 (both using libfaac) at
the command-line on Windows 7. 0.6.1 is if anything slightly faster, and no
quality issues.