XP, SP3, Mp3tag v.2.58.
I listen to lots of speech-only mp3 podcasts which files often I find inordinately large owing to excessively generous Bitrate and/or needless full stereo encoding by the originator. So I transcode them, using usually ffmpeg with the WinFF front end (currently v. 1.5.4.). Usual command line there will be:
-acodec libmp3lame -ac 1 -b:a 32k -ar 22050 -tag:a fourcc/tag [this last argument I have added and tried today but so far no effect].
Typically this transcoding works well and the correct play length and CBR status is reported for the (much reduced in size) mp3 file by Mp3tag, however many times (exclusively with VBR source mp3 files?) the play length and Bitrate of the output mp3 file is it seems stated wrongly by Mp3tag.
Conversely, the duration and CBR status of the same mp3 file is reported correctly in e.g. MP3DirectCut
The above command line for ffmpeg forces CBR so I assume VBR should not be / is not present as a field tag in the output.
The same results occur when transcoding using e.g. Freemake Audio Converter and the audio converter in Video to Video Converter.
At various times I have tried 'fixing' this error in the output /transcoded mp3 files by running vbrfix
or the vbr header fix in foobar2000
but the result of that usually is either vbrfix reports a CBR file and declines to operate on it or it acts on the transcoded mp3 file, but that when loaded in MP3DirectCut or in an iPod will not seek to or play beyond a certain spot in the play length; so the diagnosis by vbrfix as a VBR file was probably wrong. Much the same occurs with foobar2000's utility.
In both cases the Bitrate of the mp3 file 'fixed by vbrfix / foobar2000 is then reported by Mp3tag as having a Bitrate of 64k and CBR (before such 'fixes' were applied it reported as 48k). In all cases the actual CBR Bitrate output by ffmpeg using above command line was CBR 32k, and likewise with the other transcoders above mentioned.
Similar topics/issues e.g. at:
Please Add the Ability to Modify %VBR% field in MP3 Tag [EN]
--which as far as I can make out were(?) inconclusive on the duration misreporting.
Is it possible Mp3tag is reading residual VBR tags that are not(?) being expunged in the transcoding process by ffmpeg and the other audio converters; or is there something more recondite? As noted above, the Bitrate, duration and CBR status of the transcoded files are uniformly and correctly reported in MP3DirectCut.