As already mentinend in this thread some fanboy over at the offical Pioneer forums is making claims that VBR sucks (here and here) in that it needs more processing power compared to CBR and for various other reasons.

I would like to have a well written rebuttal of that statment based on facts so Pioneer might reconsider putting VBR support into their upcoming DJ equipment. I've ripped all my 1000+ CDs to VBR and I wouldn't want to reencode them just because Pioneer doesn't get it right. Thanks!

Don't waste your energy. Self-absorbed people like him will never change their narrow-minded opinion.

Also the CDJ-200 is not an MP3-player since it does not implement the standard.
If Pioneer really based the lack of VBR support on opinions of people like this they have made clear that they don't care. Therefore the only language Pioneer will understand is money, so look out for alternative products and don't support them any longer.

It's all up to whether an encoder works well. Good VBR encoders like Lame 3.98, Nero AAC, Vorbis work fine.

Yes, don't waste your time. That guy is completely wrong in everything he says, and he's arrogant about it too.

He talks about MP3 VBR taking "horsepower" like it's some monstrous task like raytracing or weather simulation. I haven't done any CBR vs. VBR speed tests (because I couldn't care less), but if my tiny iPod can decode MP3 VBR for 24 hours straight, I have a hard time imagining a stationary hardware player like the Pioneer units lack the computing power to decode it.

As the other guys have already said, you're wasting your time with him as he already seems to have decided that he knows exactly how VBR works when it seems fairly clear that he doesn't. However, in the second thread you link to he claims that VBR suffers from latency when making decisions regarding increasing/decreasing the bitrate when necessary.

I believe this to be true of some (or maybe most) VBR encoders, but the Hydrogenaudio LAME WIKI clearly states that... This does seem to infer that LAME VBR is intelligent enough to know what bitrate to use and when to use it rather than just guessing and using a slewed approximation with no real-time, output-related feedback which seems to be his inference for the majority of VBR encoders. I would go and point this out to Pulse, but I've wasted too much time on his type in the past to be honest.

To further back up what Raiden said earlier, there are some official MP3 compliance tests HERE (defined as "ISO/IEC international standard IS 11172, part 3 - audio"). If the Pioneer deck in question doesn't play ALL of the files in the official Layer3 compliance tarball without error (which includes a VBR test file) then it IS NOT an MP3 compliant player and, IMHO, shouldn't be marketed as such. Assuming that the player is marketed as such and fails the compliance tests (I haven't tested one, so I'm merely speculating), I'd be demanding a full refund had I bought one.

Call me paranoid, but it worries me to see the words "Pioneer National Trainer // Product Specialist" in his signature.

Cheers, Slipstreem.

No point with some of these people....I've given up arguing with people like that....just let them be all smug and happy in their small world

My thoughts exactly.

These threads are really old. I created an account to try get some kind of rebuttal out of Pulse, but I'm not even sure he's still active. I responded to the second, newer thread. There's a lot of misinformation being spun around there, like talk about transcoding VBR to CBR and whatnot. Utter nonsense!

Kudos for the effort. I may be going mad, but I think you may have used "MP3" when you mean to use "VBR" in at least one place.

Edit: and yes, his post regarding transcoding almost had me registering with the forum! Arse.

Edit 2: An average of 30 posts a day?! And he is still active; very active yesterday.

I'm not surprised. A title in nowadays industry doesn't mean much regarding competence.

No, I think I'm going mad. That post I made is quite unclear. Some other guy responded to me with a wall of verbiage that seems to completely miss the point.

Oh boy:

I'm going to mull this over a bit and respond sometime this evening... what nonsense.

Well, we have an answer of sorts over there from a different member, but it looks like pure bullcrap to me.

Windows Task Manager shows exactly the same resource usage here when playing back the same track encoded in either 128Kbps CBR or LAME VBR at -V3. I've checked this out in Winamp and Foobar2000.

He also talks about VBR as being a global thing without making any reference to actual quality setting with the phrase, "I can't tell the difference between a WAV and a 320kbps MP3 - but I CAN tell the difference between that and a VBR MP3...". Which encoder and what setting, numpty?!

Next!

Cheers, Slipstreem.

Mind, if you do decide to argue:
The argument that CQ VBR is better than <320 CBR should be easy to prove in theory, but very hard to prove in practice.
The best encoder is still not a human "ear" and can make mistakes regarding needed bitrate.
Unless you understand the encoding process well enough to defend the VBR methodology, it will be easy for a bull-headed fool to trip you up, giving him (?) another false sense of victory.

I'm specifically not joining that forum as I'm too argumentative when riled to get my point across succinctly, but it might be worth asking anyone who claims that they can hear the difference to at least take an ABX test for themselves rather than them making blind assumptions and misleading others. Refusal to do so would prove pigheadedness and/or a reluctance to discover the truth on the part of the opponent.

It doesn't matter what a person can or can't prove in theory if they hear no difference in practice.

Cheers, Slipstreem.

Oh yeah I see what you mean Canar. It's so nice of him to give you a basic lesson in computing isn't it .

Really most of what he has posted is just so much rubbish it's ridiculous. Like the suggestion setting a buffer length is a significant part (as in computer load) of decoding an mp3 frame. I'd say he's got no idea of the relative amount of cpu time to do a couple of integer instructions to set up a buffer length compared with even just one part of the mp3 decoding like the DCT for example. I hope there's a developer or two here to read this "basic computing lesson" and make some "constructive critism". Pretty funny stuff really.

Who is BDX?

I dont know, it's not me. Does anyone have a transcript of exactly what he said to banned anyway?

It wasn't me either, and I don't have a transcript but the post suggested that if compression ratio was irrelevant then a person might as well stick to WAV in the first place. There was a dig concerning the Pioneer DJ players not being true MP3 players if they didn't support VBR properly, and I thought that was totally fair to be honest.

Maybe a few more of us should join and flood them with the truth faster than they can delete it.

Cheers, Slipstreem.

I will post just to be ballsy. I don't see Pulse using any logic in their statements so I see no reason to use logic in mine. I will though.

Alright guys, I'm the guy who did the wall of verbiage. I'm here to defend myself (a little - please read what I have to say carefully before flamage ).

1) I LOVE being proven wrong. It means I've learned something. I'm here to be educated.

2) I'm a DJ first. While I have many posts at Pioneer, I'm not exclusive to their equipment - I use (and pay for) whatever fits my needs best. In fact, the only piece of Pioneer gear I currently own is a pair of headphones.

3) I did miss the point in my "wall of verbiage". I'm going to go and fix it.

4) I wasn't clear in my comment: "... I can't tell the difference between a WAV and a 320kbps MP3 - but I CAN tell the difference between that and a VBR MP3, or that and a 128kbps MP3." I should have added to that "from certain encoders". I think that it's generally accepted that certain encoders (both the software and human kind ) and the settings used with them are inferior and can really mess up the sound in your file. Please correct me if I'm wrong.

5) We know that MP3 is lossy. We know that it won't have the best sound quality when compared to a lossless algorithm - you people here at HA will know that better than anyone given the breadth of the forums. Unfortunately, MOST people who use MP3 either can't tell the difference or just don't care. As a DJ I believe it's part of my JOB to care - I don't want to be promoting BAD sounding music, as some DJ's do that go ONLY use filesharing as a means to get their music, which more often than not results in a crappy-sounding MP3 from some n00b who doesn't know any better.

6) CPU's, whether in a computer or a CD deck, have more than enough horsepower to handle a VBR, regardless of the back-end so-called extra processing that may or may not be required (I believe it is, negligible as it may be). Personally, I think that Pioneer's (shoddy) support of it comes down to not taking the time to handle all the exceptions and broken MP3's that occur with so many internet-shared MP3's out there, VBR or otherwise. It's no secret that the boys over at Serato Scratch Live have spent countless hours refining their program to handle those broken MP3's - a quick forum search over there reveals the mods and dev team constantly requesting files that don't play right so they can find out why they're broken. They're a big company, but I think Pioneer is bigger - why can't their engineers do the same?

7) In a club or other loud DJ environment, I'm pretty sure that NO ONE can tell the difference between even a 128kbps CBR MP3 and something better. I don't think it matters how good the sound system is, there's just too much ambient noise. I know I can't, as long as the MP3 is well encoded.

8) With #7 in mind, who am I to decide who can and can't hear things? So, I choose to encode my MP3's at 320kbps CBR so that I give my crowd the best possible chance at hearing the music in the way it was originally recorded.

9) With #8 in mind, who is MY ENCODER to decide what is a difficult passage or not in the VBR encoding process? I know that I'm already losing data to the encoding process, I would rather not lose any more than I have to.

10) I would say that the POINT of MP3 (or any other compression algorithm) is to reduce filesize either for storage or transfer (say over the internet). But, as mentioned in the other forum, storage is getting cheaper, as is bandwidth (at least where I live). I choose to use MP3's because the collection I carry around with me is too big to fit (in WAV format) on today's hard disks (~500GB at 320kbps) in a portable format. Since I play out with my MP3 collection and don't use CD's anymore, keeping everything in WAV would be damn near impossible unless I carted SEVERAL 1TB disks around. And since my music collection is part of my livelihood, my drive is a RAID 1 external USB enclosure. So for every drive I take, I now need TWO - cheap or not, this is getting more and more expensive. The tradeoff, for me, came at that point. I'm willing to accept MP3's lossy format at 320kbps because of practicality. I understand that other people's "tradeoff" point is different from mine.

It could be argued that I don't need that much music and there I will agree with you. Most often I could play certain shows off of less than 2 or 3 GB of files, call it 10 to 15GB of WAV files. I just never know what I'm going to need, so I carry everything.

11) I consider myself a professional when it comes to being a DJ. That means that I strive for excellence, and (perhaps unfairly) compare myself to other professionals, such as doctors. In an (admittedly flawed) analogy, a doctor with a shoddy education doesn't get a very favorable review; by the same token, a DJ using shoddy music won't either. Education is the base of the doctor's craft; music is the base of the DJ's.

Basically my point is this: VBR is an acceptable alternative to CBR these days, no question - if it's for personal use. Pioneer's lack of support for it in one CD player is crap, IMHO, as is their generally shoddy support for it. But, from my experience, VBR is easier to screw up than CBR. So, I stick with CBR because I'd really rather not take the chance, either that the CD player is going to hose it up or that my ears won't like how it sounds. I also promote using CBR's because I believe (as I said) that CBR's leave the least chance of error for people who (IMHO) SHOULD use the highest quality music that they can, or believe is good for them. I DO NOT believe that a VBR MP3 is acceptable, FOR ME, since I consider myself a professional. And since I listen to other DJ's, I like them to use good-quality stuff too

So there is another wall of verbiage for you - sorry I can't be more succinct. I'm going to go put my flame suit on and wait to see what you guys have to say

-r-

I don't have the time right now to get more in-depth (studying for a third-year computer science midterm which I have in 1.5h), but thank you for the post. You're being cogent.

Pre-echo is really obvious to trained ears, and occurs in high-order bits. That means that it can be obvious even with high noise-floors.

When making claims like "VBR is an acceptable alternative to CBR these days" Hydrogenaudio tends to require that such claims are backed up by blind testing (generally ABX tests around these parts). In most cases, properly-tuned VBR presets in LAME are indistinguishable from the original source. Nevertheless, there are particular samples for which even 320kbps CBR is not sufficient, even on shoddy hardware (I've ABXed castanets.wav on $40 headphones).

Either space is a concern or space is not a concern. I'm not convinced that LAME 320kbps CBR is sufficiently distinguishable from LAME V2 VBR to warrant the extra bits (around 60% larger). If space is not a concern, lossless should be great (around 150% larger than 320CBR), and has absolutely zero loss to worry about.

This sounds a lot more reasonable than when reading the quoted passages.
There's nothing wrong using CBR 320 with regard to minimizing the risk of wrong encoder decisions which can happen. But you should be aware that there are many possibilities for an encoder to go wrong:

• when deciding for using long or short blocks
• when deciding for l/r or m/s (decision can be avoided by using plain stereo but at the expense of a lower encoding precision as a tendency)
• when deciding for the amount of audio data required for a frame. In contrary to what you are thinking this process is involved also with CBR. CBR means constant frame data rate. Audio data rate however is variable also in the case of CBR as audio data can expand beyond frame border as well as not cover up an entire frame. It is true however that the decision process is less prone to errors when CBR or ABR is used. There is no reason however to general disbelieve in the VBR process of a good encoder like current Lame in the case of mp3.
• I'm sure there are a lot more decision making problems for an encoder no matter whether it uses CBR or VBR.

As I said it's okay to play it safe to the utmost extent if you like to and don't have to care much about file size. But in a practical sense you shouldn't feel really safer than when using -V0.
If you're looking at seriously bad encoded tracks it turns out that it's not VBR which is to blame. Take for instance extremely bad pre-echo sample eig (you'll find it in this forum). The majority of mp3 encoders will produce a very bad result even when using CBR 320. Contrast this to Lame 3.98's behavior when using best VBR quality -V0: the result isn't perfect but a lot better than that of many encoders' CBR 320 results (the Lame 3.98 CBR 320 result is of course as fine as the -V0 result).
The fact that perfection can't be achieved with mp3 is the reason why most members here prefer an encoder setting which produces smaller files than when using CBR 320. The quality achieved is identical in a practical sense no matter whether you use -V0, ABR 270 or similar, or CBR 320. Compared to such a setting most members here prefer a lower quality demand like when using -V3 or -V2, simply because there's nothing wrong with the quality except on rare occasion (in which a higher quality setting often brings only a minor improvement). So it's a personal choice which quality setting to use, quality difference is zero in most cases, and it's only about how to handle the rare exceptions to this.

Unfortunately you're a bit on a mission and you're wrong with this. You dislike VBR so much that you wrote a lot of fancy stuff about VBR's speed penalty which is really nonsense. With respect to quality you put the blame on VBR for no really existing reason (or do you have samples to back up your opinion?). You're disrespecting the fact that the results of high quality VBR settings are fine, and in those rare cases where they're not you cannot expect to get better results from CBR 320 compared to those of -V0.

If "your JOB (is) to care" use FLAC.


Did you ever do a double blind test? As much as I tried, i could not tel VBR (~128kbps) from the original on the last listening test.

Pioneer should support VBR and stfu. If using VBR presents some kind of unadvantage to some type of usages of the equipment they should just explain it to their users, instead of just not supporting VBR. Is it that hard nowadays to properly support the standard?

On the other side, if one has to use MP3 and if lots of post processing is going to be used, I think CBR 320 may be a wise choice, even if sometimes VBR may be better.

Saying that VBR is (generally) worse than CBR just reveals ignorance. Let them live in the stone age and don't the let them even know that most modern audio and video formats use VBR by default for quality reasons.

OK, I have a brief moment here before my midterm so I'm going to try to reply to some of what you have said.



I'd say no. The problem that many users come across is that the MP3's that they're using ARE NOT encoded to standard, and/or are broken in some way, and Pioneer's support for broken MP3's is questionable at best. It's absolutely unbelievable how many BAD/CORRUPT MP3's are out there that will still play in even a half-decent player/software, giving no indication that it's broken.

That said, I agree - the support should be improved to account for those corrupt MP3's that play just fine on most players/software. On the same note, Steinberg should also step up - I use Wavelab 5.0 and I can tell you for free that there are plenty of MP3's out there it can't seem to decode. But the second I throw them into Winamp (free, as we all know), presto-chango, Winamp can read it. Why can't an EXPENSIVE program like Wavelab? Weird.

The reason I try to steer the Pio forum members away from VBR is just because of the fact that many of them use filesharing for their music sources, and many of them would never bother to check if the thing is broken before trying to use it (either because they don't have the technical knowledge, don't care, or aren't aware that it's possible), which could result in a show stopper for them. As a work-around to Pio's shoddy VBR support, I just say "don't use it". I agree that my explanations up to now have been misleading; I'll stop doing that now that I know better.



Which ones? I'm curious...



I would, if the program I use to playback on supported it (Serato Scratch Live). Unfortunately for me, it doesn't. So I "accept" MP3's.



Not on VBR. But I have on other things. I'd be happy to try, just point me in the direction.



Point conceded, but I'll be looking into this a bit more when I can to see what's actually going on (if possible).



This is a good point, and something I hadn't considered before.

Thanks for everything so far. I'll keep watching this, but I have a midterm and a busy night ahead of me. I'll post when I can.

-r-

Probably the main reason is that Steinberg assumes that WaveLab users (primarily professionals or prosumers) will be working primarily with uncompressed WAV or AIFF files, as those are the two most typically used file formats in media production. Ergo, not much effort is expended on MP3 compatibility.

I guess most it said already but I'd like to close up with the basic points:

*) CBR 320 is considered the best (not counting freeformat) that MP3 can do. Of course, a good encoder and the proper settings should be used as well.

*) VBR is a better option to CBR when the target bitrate is the same (except for the poorest VBR qualities, where lack of tuning and other factors make ABR/CBR a better bet)

*) Hardware-wise, there are still many hardware (and some software?) that have some type of problem with VBR encoded files (from not showing the duraction correctly, to not seek, to not playing them correctly). Manufacturers should support it, since it is part of the standard, and if the decoder can play the whole range of kbps (from 32 to 320), there's no excuse to refuse to do so. (We are talking of a buffer big enough for a 320kbps frame, and a single check for the frame size before proceeding to decode it)

*) One cannot expect MP3 to be transparent all the times (it has known limitations) nor an encoder to be perfect. That said, the MP3 technology and the best encoders at the appropiate settings are more than adequate for audio playback for 2 channel CD audio quality in a wide range of equipment. (Maybe when hardware starts to support lossless or newer lossy codecs...)

What MP3 decoding library does Wavelab use? It's probably the decoder's fault, not Wavelab's. Of course, if Steinberg is just too cheap to update it, then...

Vorbis was designed to be used in VBR mode. The more used CBR LC AAC implementations are not really CBR, more like ABR. Almost all implementations of video codecs default to VBR: XviD, x264, MPEG-2 in DVDs, all video codecs in HD-DVD/Blu-ray, etc.

MP3 VBR got a bad reputation in the early days since the most used implementations were faulty. Nowadays, that's not the case. Not that the current implementations of VBR in MP3 encoders are perfect but, as a general rule, VBR leads to a better quality file than CBR, except in the extreme MP3 CBR 320 case and in very low bitrates (< 128 kbps, or it used to be like that).

I have 55,311 mp3 files, totalling 284,918,242,198 bytes (265 GB).

About 0.01% had issues. Most where CBRs.

Did YOU encode them yourself, or download them? And if you DID download them, where did you get them from? If it was filesharing, did you make sure they were good, and if not redownload them? How did you test to see if they were ok?



I've seen this in my very limited video encoding trials (visual is not my gig ). It's interesting; and without opening yet another can of worms I might argue that the ears are (in some people) more accurate on a per-second basis than the eyes are; the eyes blur, the ears tend to do so less. That's my experience; maybe I'm wrong, and I'm sure the videophiles out there would argue that point with me.



Offhand, I don't know. It wouldn't surprise me if it was semi-proprietary at least. I do know that you can chose between Fraunhofer and LAME on the encode side, but what versions I'd have to look. And you're right, it's not WaveLab's fault per se but the decoders'; however, Steinberg should fix it IMHO (which they may have done in version 6).



Well, yes and no. WaveLab is a high-end Audacity and not a media production suite. I'd say it's marketed towards the prosumers more than the professionals, as anyone who's serious about that type of stuff will pay the same for Cubase, Nuendo, or blow the whole wad and get ProTools. In my opinion, (and my opinion only), they should include some decent MP3 support because by the time WaveLab 5 was released, MP3 was already the de-facto standard and while the "pros" may not use it for their internal projects, I don't think it's a far stretch to say that even they have to use MP3 from time to time.

Over on the other board, Pulse made a point that I hadn't thought of, and that was brought up (I think) by m0rbidini as well:




I would hazard a guess that there IS a lot of post-processing going on, even if the player is doing nothing but playing, since the player has to be prepared to do things like scratch the audio, change the pitch and use hotcues and loops (all depending on the player, mind you). I'm not saying it's impossible, it just seems that for whatever reason the engineers at Pio have left VBR ability out, perhaps due to these reasons, and perhaps not. This is just a guess, however.

@moon (original post): if you're concerned about re-ripping your MP3's, never fear - in one of the posts you linked to originally there's a utility that pads out your VBRs to CBRs by doing nothing but adding zeros. It's (according to the author anyway) transparent and not a transcode. I've used it and it's great and FAST.

-r-

About 80% are my own CD collection. The rest is MP3 mixes by different DJs, friends, my own.

MP3gain can tell you if the file has an issue (it won't be able to process it).

1. regarding the difficulty of decoding VBR

it's hard to believe the supposed difficulty of implementing a proper mp3 decoder when an open source project (rockbox: http://rockbox.org/ ) has full support for several (and some much more hardware demanding) codecs.

old 140mhz coldfire processors are decoding ALL proper mp3 streams at about 5x - 4x realtime.

as implemented in rockbox, the mp3 decoder does not vary according to encoding strategy much, but it DOES vary significantly in regards to filesize. so the OPPOSITE argument could be made, that it is easier and faster to decode a VBR file averaging 190kbps (i.e. -V2) then it is to decode a 320kbps CBR file.

for rockbox this is generally true for most target architectures (and for all codecs other than some lossless implementations like monkey's audio and wavpack which take a decoding hit with more complicated encoding settings.)

data can be found on the rockbox site to support these claims here:
http://www.rockbox.org/twiki/bin/view/Main/IriverRuntime
http://www.rockbox.org/twiki/bin/view/Main...manceComparison

this can also be verified through lame. both encoding and decoding takes longer with CBR 320 files then it does via -V0 VBR files.

VBR encoding


CBR encoding


VBR decoding



CBR decoding


2. regarding VBR being an inferior encoding strategy to CBR

in current years (i.e. >2000 e.g. 3.90beta, since --dm-presets/--alt-presets/--presets) with lame the opposite has proved true except for specific problem samples.


later

You're mixing things in a way that it piles up according to your expectations and without any kind of sense. "Eyes blur, the ears (...) less" has nothing to do with VBR. Why do you think that?



Wavelab is definitely a professional product, not a "prosumer" product. It's not supposed to be a "media production suite" since it's more specific to mastering and general audio editing. It costs about the same as Cubase 4. Recently Steinberg introduced "Wavelab Essential" which is aimed at the enthusiast/home user.



The post processing is not a reason not to use VBR. It may be the reason for a user to choose CBR 320 because it's theoretically the best quality setting the format standard has to offer. It has been shown repeatedly (using double blind listening tests) that VBR is generally the best quality mode for MP3 in files that result in average bitrates higher than 128 kbps and lower than 320 kbps. For example: if you have a 256 kbps CBR (256 is just an example; you can use 192, 224, 160, etc.) MP3 file it's very likely that some frames would would need more than 256 kbps to achieve the same quality than other frames not so "complex". The encoder is "starving" bits in complex parts and "wastes" bits in easy to encode parts. VBR simply aims to maintain a constant level of quality throughout the encoding.

The post processing I was refering to was more something like heavy equalization and added effects (flanger, reverb, 3D emulation, etc.). If used heavily, these can make almost any kind of lossy audio file sound bad, independently of VBR or CBR mode. And that's why I said if one has to use MP3 and post processing, CBR 320 may be a wise choice, because theoretically it will suffer the least. Not because it's CBR, I repeat. (I would very much prefer to use an equipment that supports lossless formats for this.) Processing power is also not the issue regarding VBR vs CBR. Also, I'd imagine that scratch/hot cues/loops are done using already decoded audio in some kind of buffer so that's also not an issue.

Cya

Why have a long discussion when it all can be summed up with one image:



Disclaimer:
The diagram is not meant to be "accurate" and is not meant to estimate "perceived quality". In short, it's purpose is just to illustrate encoding efficiency.

I am guessing (and I don't really know anything about it) that some DJ "effects" require that the audio stream jump forward or backward a fraction of a second instantaneously, and so CBR would have a major advantage over VBR in seeking the new position.

Won't the part of the audio stream being worked on have already been decoded to a linear, uncompressed datastream and placed in a buffer by that point? Only guessing.

Cheers, Slipstreem.

PS Apologies to DJRyanJ for the dig earlier. I got the impression that you weren't prepared to listen to logic or partake in reasoned debate. How wrong I was!

DJRyanJ, kudos for making the effort to partake in our discussion.

Anyway, I though perhaps I might draw your attention to the newly opened ~128kbps MP3 listening test, that Sebastian has just started, following months of preparation.

It would be an introduction to a formal blind comparison test, and it may change your perception of ~128kbps (VBR) MP3s. We can always use another decent set of ears in these tests.

Great image, it really sums things up.

That would be a way to solve the problem, but it takes more effort in the software to do it that way. The programmer was probably just too lazy, or too time pressured, to come up with a better solution than "just use CBR!"

But maximum bitrate for LAME VBR (i.e. lame -V 0) is usually around 240 kbps. So the rightmost part of VBR graph doesn't exist in reality...

(Edit: grammar)

I'm gonna have to go and read more about how these DJ CD/MP3 players work. I was (possibly falsely) making the assumption that an audio CD would already be at least partially buffered to memory by such a player to allow tricks in real-time (you can't physically play a CD backwards... can you?) and that the MP3 data would be using the same buffer in the same way once decoded to an equivalent linear digital format and still using the same "trick" hardware/DSPs.

If the MP3 decode were performed as a big enough real-time slice then I can't see why it should behave any differently to a CD treated in the same way regardless of whether the MP3 is CBR or VBR. After all, there's only a fraction of the data to read from file in the first place compared to a CD, and VBR MP3 doesn't seem to be any harder to decode than CBR if Windows Task Manager in WinXP is anything to go by.

The above is all guesswork though. Does anyone know of a website actually explaining how these players work? I'm becoming genuinely interested now.

Cheers, Slipstreem.

Depends on genre and composition. I've seen quite a few v0 tracks averaging at 255kbps. I agree however that lame's V numbers are too biased towards low bitrates, therefore creating a shortage at high bitrates. On the other hand, the graph is right in that above 250kbps, there isn't really that much point to VBR anymore. At such high bitrates, saving space clearly is secondary to you and you want the highest possible robustness, with just safely saving a low amount of space compared to 320 CBR - and for that purpose, ABR is more efficient.

I dont know how to fix the whole issue while keeping the established V associations. If i were to propose a solution, it would be to reweight the entire V scale, so that it starts at 50kbps-typical and ends at 275kbps-typical - with the middle, V4.5, being at around 160kbps-typical. While being at it, reverse the scale to something more intuitive, so that 0 is low and 9 is high. Then map very low and very high values to ABR.

A backwards-compatible way to do that, would be to introduce an entirely new switch, i.e. -VBR, and then map the existing -V settings to that new scale.

Typical averages on that -VBR scale would then look similiar to this:
0.0 -> 50 kbps (mapped to ABR)
1.0 -> 75 kbps (mapped to ABR)
2.0 -> 100 kbps
3.0 -> 125 kbps
4.0 -> 150 kbps
5.0 -> 175 kbps
6.0 -> 200 kbps
7.0 -> 225 kbps
8.0 -> 250 kbps (mapped to ABR)
9.0 -> 275 kbps (mapped to ABR)

(all values are typical for entire mixed collections. Actual target isn't a bitrate - VBR does not target "bitrates", but quality-values)

The only problem I can see with that is that some less experienced users may start to equate such a -VBR X.X system with a percentage in quality terms. With ABR set to ~275Kbps for the -VBR 9.0 value, people could easily mistakenly assume that the -VBR 5.0 setting at ~175Kbps in VBR gives roughly half of the quality, whereas it's likely to be indistinguishable in terms of quality from ABR275 and original CD-quality content to almost all people almost all of the time.

The inaccurate rumours of VBR encoding being inadequate and second rate in general are rife enough already, and although I like your idea and see where you're coming from, I think that this would merely enforce this false perception personally.

Cheers, Slipstreem.

This is actually a very good argument, because VBR does target a quality, not a bitrate, so it only makes sense to asume that the value which one enters and its scale, represents that quality. Thus, it may indeed not be a good idea to spread the scale linear relative to bitrate. The range and remapping however IMO make sense.


I can see where you're coming from. I think that it makes sense to not unnecessarily support this myth, but i do not think that it makes sense to design lame for believers. What i mean with that is that if someone WANTS to believe that VBR is immature and is just looking for reasons to keep up that belief, then let the fool believe, instead of designing the tool for fools.

Besides, notice that via pure analysis of the datastream, there is no way to identify that a file was encoded with ABR instead of VBR. Thus, unless you upfrontly tell them, they wont even notice it. Add to this the unpopularity of >250kbps and <75kbps encodings, and i dont really see this as a big problem anymore.

- Lyx

IMO the old --preset scheme or a similar one addressed this pretty well.
With storage space growing less and less important there's not much sense for various low bitrate settings in the rather near future.
So an interesting future encoding quality scheme could be:

-economic (=-V5)
-standard (=-V2)
-extreme (=-V0)
-extreme+ (=abr 270 or similar)
-extreme++ (=cbr 320)

The emotions towards quality associated with such a classification IMO agree pretty much with the difference in quality to be expected (usually none with the extreme variants with rare exceptions).
Names for the quality settings can certainly be improved - it's just to explain the idea.
And as before there can be the old settings too for compatibility reasons and those who really need them.

Now we're just going around in circles. There was a reason why the presets were scrapped in favor of a simpler system.

Personally, the only thing which i consider "complicated" with the preset system, was the "--alt-preset" part of them :-) Besides of that, the main downside of them is that they lack scalability (there is nothing "in-between" them). The V-system on the other hand scales well, but is hopelessly unituitive. Then again, being intuitive has never been a strong point of lame (the typical reply to such concerns always is "use a gui!". Very well, the problem with GUIs is that they are vendor-specific.... if a vendor were to use non-lame terms, then they certainly wouldn't be well known - every app would use different terms).

We're also going way off-topic...

A quick heads-up (not that I've been spying). It seems that the Pioneer ProDJ forum has a new member called StormChaser who seems to be talking sense. Pulse seems to be listening to him, so maybe I owe Pulse an apology too.

Cheers, Slipstreem.