improve reporting with VBR MP3s

[aaron@…]

mplayer's output is designed to describe CBR files. when playing a VBR one, it
reports a bitrate (i think from the first frame) which is not representative of
the file as a whole, and from that derives an incorrect file length (usually
much too long, as first frames tend to be encoded at lower bitrates). i am well
aware that calculating length requires traversing all the frames in the file, so
please don't refer me back to bug 41.

i believe the following should happen:

• print out "VBR" or equivalent instead of an incorrect bitrate in the header.
• keep track of the average bitrate as the file is played.
• revise the file length prediction on the fly.
• print out the precise average bitrate when the file is finished.

[aaron@…]

i should point out that lame 3.98 does exactly this while encoding, displaying
the average bitrate as it changes over time (and it does stablize rather rapidly).

[aaron@…]

i was asked in #mplayer why this is important to me. the answer is that i do a
lot of work with VBR MP3s and need to know the bitrates of files i am playing or
examining. when mplayer reports '128kps', it is impossible to know if it's a CBR
or VBR file, and in the latter case, what the mean bitrate would be.

there is no way to find this average without going through the whole file, so
the player is what needs to pay attention and report it. a separate program
could be written to parse MP3s and report, but building it into mplayer seems
much more natural to me.

[reimar]

It is quite annoying with audio-only files, but if you just let it run for a few
seconds and then press CTRL+C, this should give you all the info:
mencoder -ovc copy -oac copy -o /dev/null -demuxer rawvideo -rawvideo w=1:h=1
/dev/zero -audiofile Inkubus\ Sukkubus/inkubussukkubus+queenofthemaylive.mp3

[aaron@…]

interesting hack, reimar. thanks. i would still much rather get the correct
answer from the normal invocation.

[reimar]

Possible, though maybe ugly fix

[aaron@…]

a more general bug about length reporting: bug 30

[aaron@…]

bash script for finding length / average bitrate of MP3s

[aaron@…]

here is a script i wrote to extract bitrate information from MP3s with mplayer's help. i'm still hoping this functionality can be patched into mplayer itself.

[compn]

* Bug 738 has been marked as a duplicate of this bug. *

[sylvain@…]

Is there some progress on this issue? As a GUI using mplayer we have regular user reports about this problem. While I know this is not a critical problem, it is however noticed by many users. It would be nice to have a better computation of total duration. Especially as patches seem avaible.

[carl@…]

Same thing with .ogg

carl@gw42:~/a$ mplayer -identify red_blue-3-mlt-trunk.ogg
MPlayer 1.0rc2-4.3.3 (C) 2000-2007 MPlayer Team
CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (Family: 15, Model: 43, Stepping: 1)
CPUflags: MMX: 1 MMX2: 1 3DNow: 1 3DNow2: 1 SSE: 1 SSE2: 1
Compiled with runtime CPU detection.
mplayer: could not connect to socket
mplayer: No such file or directory
Failed to open LIRC support. You will not be able to use your remote control.

Playing red_blue-3-mlt-trunk.ogg.
ID_VIDEO_ID=0
[Ogg] stream 0: video (Theora v3.2.1), -vid 0
ID_AUDIO_ID=0
[Ogg] stream 1: audio (Vorbis), -aid 0
Ogg file format detected.
VIDEO: [theo] 720x480 24bpp 29.970 fps 0.0 kbps ( 0.0 kbyte/s)
ID_FILENAME=red_blue-3-mlt-trunk.ogg
ID_DEMUXER=ogg
ID_VIDEO_FORMAT=theo
ID_VIDEO_BITRATE=0
ID_VIDEO_WIDTH=720
ID_VIDEO_HEIGHT=480
ID_VIDEO_FPS=29.970
ID_VIDEO_ASPECT=0.0000
ID_AUDIO_FORMAT=vrbs
ID_AUDIO_BITRATE=0
ID_AUDIO_RATE=44100
ID_AUDIO_NCH=2
ID_LENGTH=31924.69

carl@gw42:~/a$ ogginfo red_blue-3-mlt-trunk.ogg
Processing file "red_blue-3-mlt-trunk.ogg"...

Note: Stream 1 has serial number 0, which is legal but may cause problems with some tools.
New logical stream (#1, serial: 00000000): type theora
New logical stream (#2, serial: 00000001): type vorbis
Theora headers parsed for stream 1, information follows...
Version: 3.2.1
Vendor: Xiph.Org libTheora I 20081020 3 2 1
Width: 720
Height: 480
Total image: 720 by 480, crop offset (0, 0)
Framerate 30000/1001 (29.97 fps)
Pixel aspect ratio 8:9 (0.888889:1)
Frame aspect 4:3
Colourspace unspecified
Pixel format 4:2:0
Target bitrate: 600 kbps
Nominal quality setting (0-63): 0
Vorbis headers parsed for stream 2, information follows...
Version: 0
Vendor:
Channels: 2
Rate: 44100

Nominal bitrate not set
Upper bitrate not set
Lower bitrate not set
Negative or zero granulepos (0) on vorbis stream outside of headers. This file was created by a buggy encoder
Vorbis stream 2:

Total data length: 16747510 bytes
Playback length: 33m:15.290s
Average bitrate: 67.148150 kb/s

Logical stream 2 ended
Theora stream 1:

Total data length: 2325723 bytes
Playback length: 33m:15.293s
Average bitrate: 9.324837 kb/s

Logical stream 1 ended

[first.contact@…]

Some comments on this issue:

Concerning how to fix this, you may take a look at ​http://sourceforge.net/projects/mp3check which is able to determine the correct length of any MP3.

Concerning the priority: right now mplayer returns _wrong_ ID_LENGTH values. This is worse than reporting nothing at all, because, as said in comment #9, most graphical frontends use time to seek within files. As ID_LENGTH cannot be trusted any longer, mplayer becomes unusable as an reliable MP3 player, because if the reported length is higher than the real length, playing will stop if one seeks outside the file. Imagine you want to to jump to the middle of a song, and then the playing stops because ID_LENGTH was twice as big as the actual length... really annoying.

So please, fix this (either by determining the correct length or by returning no length at all).