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@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-user

To unsubscribe, visit link above, or email ffmpeg-user-request@ffmpeg.org with subject "unsubscribe".