Opened 14 years ago

Last modified 8 years ago

#465 assigned enhancement

improve reporting with VBR MP3s

Reported by: aaron@… Owned by: reimar
Priority: normal Component: core
Version: HEAD Severity: minor
Keywords: Cc: codon1@…, roweigert@…,…
Blocked By: Blocking:
Reproduced by developer: Analyzed by developer:


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.

Attachments (2)

mp3br_update.diff (780 bytes) - added by reimar 14 years ago.
Possible, though maybe ugly fix (490 bytes) - added by aaron@… 13 years ago.
bash script for finding length / average bitrate of MP3s

Download all attachments as: .zip

Change History (16)

comment:1 Changed 14 years ago by dominik@…

  • Severity changed from normal to enhancement

comment:2 Changed 14 years ago by 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).

comment:3 Changed 14 years ago by 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.

comment:4 Changed 14 years ago by 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

comment:5 Changed 14 years ago by aaron@…

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

Changed 14 years ago by reimar

Possible, though maybe ugly fix

comment:6 Changed 14 years ago by reimar

comment:7 Changed 14 years ago by reimar

  • Owner changed from alex@… to Reimar.Doeffinger@…
  • Status changed from new to assigned

comment:8 Changed 13 years ago by aaron@…

a more general bug about length reporting: bug 30

Changed 13 years ago by aaron@…

bash script for finding length / average bitrate of MP3s

comment:9 Changed 13 years ago by 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.

comment:10 Changed 13 years ago by compn

  • Cc codon1@… added

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

comment:11 Changed 12 years ago by 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.

comment:12 Changed 11 years ago by 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.
[Ogg] stream 0: video (Theora v3.2.1), -vid 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)

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
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

comment:13 Changed 10 years ago by…

  • Cc… added

Some comments on this issue:

Concerning how to fix this, you may take a look at 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).

comment:14 Changed 8 years ago by t.artem@…

  • Cc roweigert@… added
Note: See TracTickets for help on using tickets.