[F] VBR field strangeness



Using iTunes for Windows, I imported some spoken word files from CD with AAC encoder, 128kbps VBR. The iTunes "Bit Rate" column shows "128 kbps (VBR)". For the same files, Mp3tag 2.45d shows a number from "106 kBits/s" to "109 kBits/s" in its "Bitrate" column. This isn't necessarily a problem -- I understand that the two programs may use different metrics or report target versus actual kbps. But the "VBR" column of Mp3tag is blank, and that seems like a problem: whether the value reflects a measurement or a tag, it's a binary value on/off and in these files it's on.

Suppose I change the 'title' field of a track in Mp3tag, then do a "get info" within iTunes. ITunes reads the (revised) ID3 tags and changes its database to reflect the divisions, and will rename the file if the relevant (initial) part of the 'title' field has changed. This is all as expected. But iTunes subsequently reports something different in the "Bit Rate" column for the track: it shows "128 kpbs" now, without the VBR designation. Same difference in the "Get Info/Summary" tab of iTunes.

It's of minor importance to me whether iTunes reports the VBR flag correctly or not for these tracks, but I'm concerned that Mp3tag may be doing more than expected when I think I'm altering the ID3 "title" field of a track and nothing more. It's doing something that causes iTunes to report VBR information incorrectly.


Thanks for reporting! This should now be fixed with Mp3tag v2.46.

Edit: Just to clarify: iTunes now has a specific tag field which stores the VBR info as binary data which wasn't supported by Mp3tag. The old version removed parts of this information but did not change any of the audio data. The new version now preserves this data.



I'd like to follow up on this topic.

I have some VBR MP3s generated from the good old Real Player , and VBR MP4s generated from Audacity, in turn from FFMpeg, in turn from libavcodec and libavformat.

Those file show strange bitrate fields, such as 86K for some MP3s, which I believe I used at least 192K VBR.

I don't know how these two programs stored this kind of information in the output files. Am I asking too much to add support of them ? :laughing:

This is a very minor issue, if this is one....



this may not apply, but have you tried running mp3val on them? or moonbases ver of vbrfix?

sometimes problems like that are fixed in the LAME headers.