[FFmpeg-user] Why _COPYing_ a variable encoded audio (AAC) channel will produce a variably encoded one?

[Zak]

Hello Sophoklis,

Short version:
I strongly suspect the audio data was copied directly and simply. I 
strongly suspect it is bit-for-bit identical audio data, it was not 
decompressed and recompressed with different settings.

Advice for you:
I am not sure this is the case, we will have more evidence if you can 
give the full FFmpeg printed output, including STDOUT and STDERR. Just 
issue the command and copy-paste everything out of the terminal 
emulator. I also recommend running ffprobe on the input and the output 
and pasting that data too, so you will do a total of three commands.

Disclaimer: I know absolutely nothing about the 3GP container file format.

I do know a fair amount about audio compression algorithms, including AAC.

I have several pieces of evidence that FFmpeg did not modify the audio data:

1. The original metadata is suspicious based on my knowledge of AAC. It 
says the "Bit rate" is "32.0 kb/s" for the original, but it is not clear 
which aspect it is referring to. Is that the average bitrate calculated 
by actually counting bytes and dividing by the duration in seconds? Or 
is that the average bitrate based on reading some metadata in the 3GP 
file and trusting it on faith? I suspect the latter is more likely. It 
may even be a target given to the AAC encoder, and the user-specified 
target bitrate is different than the final bitrate that was actually 
achieved depending on the audio content and the other settings given to 
the encoder.

1.B. The other extremely suspicious thing is that "Bit rate" (unclear 
meaning) is 32.0 kb/s, but "Maximum bit rate" (clear meaning, but may 
not be accurate) is 34.4 kb/s, which is only 7.5% larger. Now, the AAC 
codec allows you to specify entirely arbitrary bitrates, so it is 
possible to ask for variable bitrate (VBR), target of 32 kb/s, and 
maximum of 34.4 kb/s. That is a very weird thing to ask for, and you 
would need to supply an argument for the maximum bitrate (unless the 
audio signal is very weird). You can ask for that, but I doubt anyone 
asked for that. A much more common thing to ask for is variable bitrate 
(VBR), target of 256 kb/s, and maximum of 320 kb/s. Note that 320 is a 
full 25% larger than 256, which allows the encoder to actually take 
advantage of the VBR benefits. If you only give it 7.5% to work with, 
you might as well ask for constant bitrate (CBR), which I suspect is 
what they actually did.

1.C. The frame rate and samples per frame are identical in the input and 
the output.

1.D. The size of the audio data is identical in the input and the output.

2. I think all of the data that appears different for the two formats, 
3GP and M4A, is almost certainly due to how the metadata is stored in 
those two different container types and where FFmpeg reads the data 
from. I know absolutely nothing about 3GP, but it is quite possible that 
it stores some of that data in the file, and FFmpeg is just reading it 
and displaying it, even if it is incorrect. I do know a fair about about 
M4A, the spec for how to store metadata is not standardized at all, and 
it is entirely possible to store a bitrate that is just not true. Many 
pieces of software will read it, display it, and it just isn't the 
bitrate of the audio.

What you really want is a software tool that can count the number of 
bytes of audio data, and calculate the duration in seconds (not read it 
from metadata, actually decode the audio and measure how long it is), 
and then give you the actual bitrate. I don't know any software that 
does this for M4A and AAC, sadly. A piece of software that does this for 
MP3 is Mutagen (Python library). I suspect MediaInfo may be able to do 
this for M4A containers and AAC data. MediaInfo can probably also handle 
the 3GP container.

If you give me an MP3 file or an Ogg Vorbis file, I can "fool" FFmpeg 
into saying that it is a very wrong bitrate and duration. The forged 
file will probably play in VLC, but there are many pieces of software 
that probably would give errors. I don't know M4A as well, but M4A is 
even more haphazard, so it is probably very easy to mess up the bitrate 
and duration data, especially by accident. MP3 files rarely have this 
type of error by accident, except maybe a 2-second error if the MP3 was 
ripped from a CD with a 2-second pregap. I have seen this cause media 
players to skip to the next song 2 seconds before the current song 
actually ended. iTunes and VLC will not be fooled, but many things will 
mess up.

Zak

On 2/28/18 7:40 AM, Sophoklis Goumas wrote:
> Hello.
>
> I have a .3gp file containing a video and an audio channel.
>
> I'm trying to get the audio channel in a separate m4a file but when I issue:
> ffmpeg -i foo.3gp -vn -c:a copy foo.m4a
> I get a constantly encoded AAC audio channel
> while the original was a variably encoded one.
>
> In more detail, from this:
> Format                : AAC
> Format/Info           : Advanced Audio Codec
> Format profile        : LC
> Codec ID              : mp4a-40-2
> Bit rate mode         : Variable
> Bit rate              : 32.0 kb/s
> Maximum bit rate      : 34.4 kb/s
> Channel(s)            : 1 channel
> Channel positions     : Front: C
> Sampling rate         : 22.05 kHz
> Frame rate            : 21.533 FPS (1024 SPF)
> Compression mode      : Lossy
> Stream size           : 82.4 MiB (60%)
>
> I end up with this:
>
> Format                : AAC
> Format/Info           : Advanced Audio Codec
> Format profile        : LC
> Codec ID              : mp4a-40-2
> Bit rate mode         : Constant
> Bit rate              : 32.0 kb/s
> Channel(s)            : 2 channels
> Channel(s)_Original   : 1 channel
> Channel positions     : Front: C
> Sampling rate         : 22.05 kHz
> Frame rate            : 21.533 FPS (1024 SPF)
> Compression mode      : Lossy
> Stream size           : 82.4 MiB (98%)
> Default               : Yes
> Alternate group       : 1
>
> Thanks in advance,
> Sophoklis
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>
> To unsubscribe, visit link above, or email
> ffmpeg-user-request at ffmpeg.org with subject "unsubscribe".