IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
Methods for player(s) with VBR issues, split from 'replaygain' thread
Destroid
post Jul 6 2012, 00:54
Post #1





Group: Members
Posts: 545
Joined: 4-June 02
Member No.: 2220



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

QUOTE (halb27 @ Jul 5 2012, 07:01) *
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

-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?"
Go to the top of the page
+Quote Post
halb27
post Jul 6 2012, 07:11
Post #2





Group: Members
Posts: 2424
Joined: 9-October 05
From: Dormagen, Germany
Member No.: 25015



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


--------------------
lame3100m -V1 --insane-factor 0.75
Go to the top of the page
+Quote Post
DonP
post Jul 6 2012, 12:34
Post #3





Group: Members (Donating)
Posts: 1471
Joined: 11-February 03
From: Vermont
Member No.: 4955



QUOTE (Destroid @ Jul 5 2012, 19:54) *
To recap:
[i]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.

Go to the top of the page
+Quote Post
The Irish Man
post Jul 6 2012, 13:17
Post #4





Group: Members
Posts: 15
Joined: 9-November 02
From: Connemara, Eire
Member No.: 3737



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.
Go to the top of the page
+Quote Post
db1989
post Jul 6 2012, 13:39
Post #5





Group: Super Moderator
Posts: 5275
Joined: 23-June 06
Member No.: 32180



…which actually will probably be treated as though it were -b32.
Go to the top of the page
+Quote Post
Destroid
post Jul 6 2012, 20:01
Post #6





Group: Members
Posts: 545
Joined: 4-June 02
Member No.: 2220



QUOTE (halb27 @ Jul 6 2012, 06:11) *
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


QUOTE (DonP @ Jul 6 2012, 11:34) *
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 dry.gif ).


QUOTE (The Irish Man @ Jul 6 2012, 12:17) *
...had to add [-b 16] to my lame encoder setting before they would play.

QUOTE (db1989 @ Jul 6 2012, 12:39) *
…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" rolleyes.gif Now the investigation turns toward whether it scans the whole file or just part of it...

This post has been edited by Destroid: Jul 6 2012, 20:10


--------------------
"Something bothering you, Mister Spock?"
Go to the top of the page
+Quote Post
robert
post Jul 7 2012, 08:29
Post #7


LAME developer


Group: Developer
Posts: 788
Joined: 22-September 01
Member No.: 5



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

This post has been edited by robert: Jul 7 2012, 08:31
Go to the top of the page
+Quote Post
Destroid
post Jul 8 2012, 00:19
Post #8





Group: Members
Posts: 545
Joined: 4-June 02
Member No.: 2220



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). blink.gif


--------------------
"Something bothering you, Mister Spock?"
Go to the top of the page
+Quote Post
Porcus
post Jul 8 2012, 06:01
Post #9





Group: Members
Posts: 1842
Joined: 30-November 06
Member No.: 38207



QUOTE (Destroid @ Jul 6 2012, 21:01) *
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.



QUOTE (robert @ Jul 7 2012, 09:29) *
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?)


--------------------
One day in the Year of the Fox came a time remembered well
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 28th July 2014 - 18:30