Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Methods for player(s) with VBR issues (Read 6713 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Methods for player(s) with VBR issues

This topic had suggestions for dealing with VBR on less-than robust players. Hence, this new thread for discussion.

To recap:
I require CBR since I am unfortunate to have one player that screws up VBR. In most cases it plays 90% files OK but many songs do not play to the end...

...Can anyone else with 'VBR issues' relate to this?...I would like to see how my player would negotiate a VBR file where the first frame was null/dummy having a bitrate equal or lesser to the overall average bitrate of the file. (I imagine it would screw up gapless but this player can't negotiate that either, nor replaygain, of course.)

If player problems with VBR are the issue you have more options besides plain -b 128 or plain -V5:

a) -V5 -b 128 -B 128 -F thus restricting frame size to 128 kbps frames but still using the VBR audio data production machinery. Quality can be better than that produced by CBR 128. Not clear though whether or not clipping can occur like with CBR because of the restricted frame bitrate as it has not become clear yet for what specific reasons CBR/ABR is more clipping prone than VBR is.

b) use -V5 and have Omion's mp3repacker tool losslessly create a CBR file from the -V5 file. You have to accept though that resulting CBR bitrate can get higher than 128 kbps depending on your music.

The durations below are reported from the device (LAME 3.99.5 and Mp3packer 1.22 used).
Code: [Select]
-b 128                                4:14
-V 5                                  3:29
-V 5 + mp3packer -z                  3:29
-V 5 -b 128 -B 128 -F                4:13 (song fades to silence, missing portion not noticeable)
-V 5 -b 128 -B 128 -F + mp3packer -z  4:16 (plays only to 4:14 before advancing)
The point of the last test file was to see what (if any) behavior changes would happen. As it turns out, seeking doesn't work correctly after VBR-ing that file. Mp3packer reported the minimum bitrate for the -V 5 file 256 kbps, so I didn't bother with the Mp3packer CBR method, as I would just encode straight to 256 kbps since I have the option. Basically I'm still looking to identify the cause of my player's issue since there is no good reason to not use VBR, unless (as in this case) the player doesn't behave properly.
"Something bothering you, Mister Spock?"

Methods for player(s) with VBR issues

Reply #1
mp3packer's -z option isn't helpful with Lame, and it makes the otherwise fast procedure slow.
But I was talking about the 'make CBR' feature of mp3packer. The minimum frame bitrate reported isn't necessarily the resulting CBR bitrate. I'm afraid however that converting -V5 to CBR will often result in a higher bitrate than 128 kbps.

I guess that a combination of the two procedures I proposed will do best:
apply the mp3packer CBR feature to the result of -V5 -B 160 or -V5 -B 192 (try them both in order to find out what best fits your needs).
lame3995o -Q1.7 --lowpass 17

Methods for player(s) with VBR issues

Reply #2
To recap:
I require CBR since I am unfortunate to have one player that screws up VBR. In most cases it plays 90% files OK but many songs do not play to the end...


Is the player a program (software or firmware) that may have an update available?  I've had good luck in the past getting fixes for players that couldn't play files with unusual (but valid) settings like monophonic.


Methods for player(s) with VBR issues

Reply #3
Used to have 2 CD players a few years back, where I Work,
that for some reason would not play
MP3 VBR files with zero bitrate anywhere in the file. (usually at start & end of song)
had to add [-b 16] to my lame encoder setting before they would play.


 

Methods for player(s) with VBR issues

Reply #5
I guess that a combination of the two procedures I proposed will do best:
apply the mp3packer CBR feature to the result of -V5 -B 160 or -V5 -B 192 (try them both in order to find out what best fits your needs).

Thank you for your additional suggestions.

The combination of setting -B 160/192 and then running Mp3packer (without the -z switch this time, thanks again for the advice) resulted in files that played to the end (4:14), as expected.

As for the non-Mp3packed files:

-V 5 -B 160 = 3:52
-V 5 -B 192 = 3:34

To explore this pattern further, I used --abr at 128, 112 & 100. Mp3packer claimed minimum bitrates of 256, 224 and 224, respectively.

--abr 128 = 3:57
--abr 112 = 4:00
--abr 100 = 4:07


Is the player a program (software or firmware) that may have an update available?

Not that I know of, but I'll check again. To end the mystery, the player is a pre-pay cellular device model LG 900, which I chose specifically for its MicroSD card slot and 1/8" headphone jack (and price, I guess  ).


...had to add [-b 16] to my lame encoder setting before they would play.

…which actually will probably be treated as though it were -b32.

From my tests, it seems something is going wrong when higher bitrate frames are present. At the last minute I encoded one more file (Mp3packer minimum bitrate = 192):

-V 5 -b 64 -B 192 = 3:34

I would like get to the bottom of this issue. I'll stick to CBR until I isolate why the duration is calculated wrong with VBR, yet, appears to have no problem with decoding the files.

edit: noticed duration of "-V 5 -B 192" is the same as "-V 5 -b 64 -B 192"  Now the investigation turns toward whether it scans the whole file or just part of it...
"Something bothering you, Mister Spock?"

Methods for player(s) with VBR issues

Reply #6
If you really want to make VBR files at a fixed bitrate, don't forget to add -F to force minimum bitrate. Without that switch, silent parts are still encoded at lower bitrates.
[font= "Lucida Console"]lame -V5 -b128 -B128 -F song.wav[/font]

Methods for player(s) with VBR issues

Reply #7
Thanks for mentioning that, robert. I wondered why I saw those 32kbps frames in the last trial. I re-ran the encode and also tried some VBR encodes using Helix (v5.1) and FhG (command line v1.5), max frame reported by Mp3packer 1.22:

LAME -V5 -b64 -B192 -F = 3:33  (max frame = 192 kbps)
Helix -V100 -X2 -U2 =  4:42 (max frame = 224 kbps)
Helix -V120 -X2 -U2 =  4:38 (max frame = 256 kbps)
FhG -br 0 -m 3 -vbri = 4:36 (max frame = 192 kbps)
FhG -br 0 -m 2 -vbri = 4:36 (max frame = 224 kbps)

With LAME VBR I was convinced the player (mis)calculated by using something like: (Duration) = (Filesize) / (MaxBitrateDetected). The other encoders showed a different picture. The Helix and Fhg could seek without major issue, much better than the LAME experiment from the first post.

I also don't think other data in the MP3 header or ID3v2 tag could be factor (none of the test files were tagged, other than LAME tag). Also, I didn't see any major issues with bitrate distributions reported by Mp3packer (all files used some 32 kbps frames). 
"Something bothering you, Mister Spock?"

Methods for player(s) with VBR issues

Reply #8
Mp3packer claimed minimum bitrates of 256, 224 and 224, respectively.


Precisely what did you do to get that information out?
If you refer to the number that WINmp3packer reports 'at the beginning of the repacking process', that figure is a guess based on just the very beginning of the file. In my experience, that is notoriously unreliable.
If you refer to the number that mp3packer outputs using the --ib switch, then that is the minimum bitrate it could compress to if you want to enforce CBR.



If you really want to make VBR files at a fixed bitrate, don't forget to add -F to force minimum bitrate. Without that switch, silent parts are still encoded at lower bitrates.
lame -V5 -b128 -B128 -F song.wav


(Would -V5 make any difference here, where the -b number equals the -B number?)