mp3 bitrate and duration wrong

[icom]

The attached mp3 file was encoded with ffmpeg, using the aax audio converter utility

When reading metadata with exiftool, it reports a bitrate 64 kbps and a duration of 13.56 s (using exiftool 11.49 on win10 home, version 1809).
However, the real bitrate of the mp3 is 128 kbps and the real duration is 6 s, which ist correctly shown in windows file properties as well as in groove media player (at least the duration is shown there directly), or also by ffprobe utility being part of ffmpeg package

The application "mp3tag" on the other hand, which I'm normally using for mp3 tag management, is showing exactly the same wrong behaviour as exiftool. But every mediaplayer I'm testing is playing the file properly.
And it's not only one file affected - every single file encoded with the ffmpeg utility shows the same behaviour.

Any ideas on this?

[Hayo Baan]

Interesting, it looks as if exiftool misiterprets the bitrate; the time is reported as twice as long as it really is too.

[Phil Harvey]

I think this is a problem with the way the file is encoded.

I opened the MP3 in iTunes, and it says it is 13 seconds long, although when I play it the audio cuts out half way through.

The duration ExifTool calculates is based on the bitrate, and is approximate:

Code Select Expand

[Composite]     Duration                        : 13.56 s (approx)

So if the bitrate is wrong in the MPEG header, the duration will also be wrong.

ExifTool agrees with iTunes, so I don't think there is any reason to look deeper into this.   It is possible to calculate an exact bitrate by processing the audio stream itself, but that is not something that ExifTool will do (it isn't an audio player).

- Phil

[Hayo Baan]

Interesting, I opened the file in QuickTime and there the info panel told me it was a 7 second recording of 128kbits/s. Strange that iTunes reports it differently. I wonder what could make the difference here; from what I could tell from the -v3 output of exiftool, the bitrate is actually determined from an integer value (5 in this case), so there isn't much that could have gone wrong... That said, how do the players then determine it needs to be played at 128, and not 64 kbits/s?

[ryerman]

Any ideas on this?

I use VBRfix whenever I see this problem. (https://hydrogenaud.io/index.php/topic,67076.0.html)

Code Select Expand

W:\>exiftool -ver
11.40

Output for original file

Code Select Expand

W:\>exiftool -config "" -a -s -G1 -MPEG:all -COMPOSITE:all 1.mp3
[MPEG]          MPEGAudioVersion                : 1
[MPEG]          AudioLayer                      : 3
[MPEG]          AudioBitrate                    : 64 kbps
[MPEG]          SampleRate                      : 44100
[MPEG]          ChannelMode                     : Stereo
[MPEG]          MSStereo                        : Off
[MPEG]          IntensityStereo                 : Off
[MPEG]          CopyrightFlag                   : False
[MPEG]          OriginalMedia                   : False
[MPEG]          Emphasis                        : None
[Composite]     DateTimeOriginal                : 2018
[Composite]     Duration                        : 13.56 s (approx)

Output for fixed file

Code Select Expand

W:\>exiftool -config "" -a -s -G1 -MPEG:all -COMPOSITE:all 1(vbrfixed).mp3
[MPEG]          MPEGAudioVersion                : 1
[MPEG]          AudioLayer                      : 3
[MPEG]          AudioBitrate                    : 64 kbps
[MPEG]          SampleRate                      : 44100
[MPEG]          ChannelMode                     : Stereo
[MPEG]          MSStereo                        : Off
[MPEG]          IntensityStereo                 : Off
[MPEG]          CopyrightFlag                   : False
[MPEG]          OriginalMedia                   : False
[MPEG]          Emphasis                        : None
[MPEG]          VBRFrames                       : 260
[MPEG]          VBRBytes                        : 108667
[MPEG]          VBRScale                        : 0
[Composite]     AudioBitrate                    : 128 kbps
[Composite]     DateTimeOriginal                : 2018
[Composite]     Duration                        : 6.79 s (approx)

[icom]

Hey ryerman, that looks great - I'll check VBRfix when I'm back home ... thanks!

@Phil - I already agreed that it does not really look like an exiftool problem, even before I read ryermans reply; however, exiftool (and other SW) definitely show misleading results, which seem to be caused by some "mistake"/"mismatched encoding" (?) and I am interested to pinpoint the source of these, because I did not expect this to be possible at all. Also the exiftool outputs of ryermans fixed mp3 still show a wrong audiobitrate within the mpeg tags, although the composite value of audiobitrate is correct now.

- icom

[Phil Harvey]

That said, how do the players then determine it needs to be played at 128, and not 64 kbits/s?

The bitrate has nothing to do with how it is played.  The sample rate determines the playback speed.  The bitrate is just a target compression setting used during encoding.

- Phil

[icom]

Thanks again to all involved  - VBRfix really works "quick & easy".

So in principle my problem is solved - or better: I know how to solve, when it occurs.
Next step should be to avoid the problems during encoding.

-icom

[John Weems]

Does anyone know how to distinguish the encoding way of an aax audio converter? I am planning to test the audkit aax audio converter. Its conversion speed is so fast that I am really interested in it.