Skip to main content

Topic: Informed rebuttal of VBR disadvantages appreciated (Read 32647 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • Ron Jones
  • [*][*][*][*]
Informed rebuttal of VBR disadvantages appreciated
Reply #25
Why can't an EXPENSIVE program like Wavelab [decode broken MP3s]?

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.

  • [JAZ]
  • [*][*][*][*][*]
Informed rebuttal of VBR disadvantages appreciated
Reply #26
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...)
  • Last Edit: 16 October, 2008, 06:02:37 PM by [JAZ]

  • Axon
  • [*][*][*][*][*]
  • Members (Donating)
Informed rebuttal of VBR disadvantages appreciated
Reply #27
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...

  • m0rbidini
  • [*][*][*]
Informed rebuttal of VBR disadvantages appreciated
Reply #28
Quote
... don't ... let them even know that most modern audio and video formats use VBR by default for quality reasons.

Which ones?  I'm curious...


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

  • kwanbis
  • [*][*][*][*][*]
  • Developer (Donating)
Informed rebuttal of VBR disadvantages appreciated
Reply #29
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.

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

About 0.01% had issues. Most where CBRs.

  • DJRyanJ
  • [*]
Informed rebuttal of VBR disadvantages appreciated
Reply #30
Quote
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?

Quote
Almost all implementations of video codecs default to VBR: XviD, x264, MPEG-2 in DVDs, all video codecs in HD-DVD/Blu-ray, etc.


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.

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


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

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


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:

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

Quote
There's more to just the decoding - it takes a lot of processing power for the ability to decode ahead of the playback at variable speeds and provide accurate buffer data flow regardless of what the user does with the platter, pitch or hotcues.


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-
  • Last Edit: 16 October, 2008, 11:51:40 PM by DJRyanJ

  • kwanbis
  • [*][*][*][*][*]
  • Developer (Donating)
Informed rebuttal of VBR disadvantages appreciated
Reply #31
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?

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).
  • Last Edit: 17 October, 2008, 12:06:49 AM by kwanbis

  • xmixahlx
  • [*][*][*][*][*]
Informed rebuttal of VBR disadvantages appreciated
Reply #32
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
Code: [Select]
mike@xmixahlx:~$ time lame -V6 --silent --noreplaygain 41_30sec.wav 41_30sec-V6.mp3

real    0m1.222s
user    0m1.216s
sys     0m0.004s
mike@xmixahlx:~$ time lame -V5 --silent --noreplaygain 41_30sec.wav 41_30sec-V5.mp3

real    0m1.298s
user    0m1.276s
sys     0m0.016s
mike@xmixahlx:~$ time lame -V4 --silent --noreplaygain 41_30sec.wav 41_30sec-V4.mp3

real    0m1.313s
user    0m1.284s
sys     0m0.016s
mike@xmixahlx:~$ time lame -V3 --silent --noreplaygain 41_30sec.wav 41_30sec-V3.mp3

real    0m1.342s
user    0m1.328s
sys     0m0.016s
mike@xmixahlx:~$ time lame -V2 --silent --noreplaygain 41_30sec.wav 41_30sec-V2.mp3

real    0m1.409s
user    0m1.400s
sys     0m0.008s
mike@xmixahlx:~$ time lame -V1 --silent --noreplaygain 41_30sec.wav 41_30sec-V1.mp3

real    0m1.580s
user    0m1.408s
sys     0m0.016s
mike@xmixahlx:~$ time lame -V0 --silent --noreplaygain 41_30sec.wav 41_30sec-V0.mp3

real    0m1.482s
user    0m1.448s
sys     0m0.024s


CBR encoding
Code: [Select]
mike@xmixahlx:~$ time lame -b 128 --silent --noreplaygain 41_30sec.wav 41_30sec-128.mp3

real    0m2.064s
user    0m2.052s
sys     0m0.016s
mike@xmixahlx:~$ time lame -b 160 --silent --noreplaygain 41_30sec.wav 41_30sec-160.mp3

real    0m2.154s
user    0m2.120s
sys     0m0.032s
mike@xmixahlx:~$ time lame -b 192 --silent --noreplaygain 41_30sec.wav 41_30sec-192.mp3

real    0m1.770s
user    0m1.768s
sys     0m0.000s
mike@xmixahlx:~$ time lame -b 224 --silent --noreplaygain 41_30sec.wav 41_30sec-224.mp3

real    0m1.807s
user    0m1.768s
sys     0m0.012s
mike@xmixahlx:~$ time lame -b 256 --silent --noreplaygain 41_30sec.wav 41_30sec-256.mp3

real    0m1.779s
user    0m1.752s
sys     0m0.028s
mike@xmixahlx:~$ time lame -b 320 --silent --noreplaygain 41_30sec.wav 41_30sec-320.mp3

real    0m1.686s
user    0m1.676s
sys     0m0.008s


VBR decoding
Code: [Select]
mike@xmixahlx:~$ time lame --silent --decode 41_30sec-V6.mp3 

real    0m0.271s
user    0m0.252s
sys     0m0.008s
mike@xmixahlx:~$ time lame --silent --decode 41_30sec-V5.mp3

real    0m0.273s
user    0m0.256s
sys     0m0.004s
mike@xmixahlx:~$ time lame --silent --decode 41_30sec-V4.mp3

real    0m0.270s
user    0m0.248s
sys     0m0.020s
mike@xmixahlx:~$ time lame --silent --decode 41_30sec-V3.mp3

real    0m0.272s
user    0m0.256s
sys     0m0.016s
mike@xmixahlx:~$ time lame --silent --decode 41_30sec-V2.mp3

real    0m0.289s
user    0m0.272s
sys     0m0.020s
mike@xmixahlx:~$ time lame --silent --decode 41_30sec-V1.mp3

real    0m0.289s
user    0m0.276s
sys     0m0.008s
mike@xmixahlx:~$ time lame --silent --decode 41_30sec-V0.mp3

real    0m0.293s
user    0m0.272s
sys     0m0.020s



CBR decoding
Code: [Select]
mike@xmixahlx:~$ time lame --silent --decode 41_30sec-128.mp3 

real    0m0.256s
user    0m0.240s
sys     0m0.016s
mike@xmixahlx:~$ time lame --silent --decode 41_30sec-160.mp3

real    0m0.267s
user    0m0.256s
sys     0m0.012s
mike@xmixahlx:~$ time lame --silent --decode 41_30sec-192.mp3

real    0m0.274s
user    0m0.264s
sys     0m0.008s
mike@xmixahlx:~$ time lame --silent --decode 41_30sec-224.mp3

real    0m0.285s
user    0m0.256s
sys     0m0.028s
mike@xmixahlx:~$ time lame --silent --decode 41_30sec-256.mp3

real    0m0.291s
user    0m0.280s
sys     0m0.008s
mike@xmixahlx:~$ time lame --silent --decode 41_30sec-320.mp3

real    0m0.306s
user    0m0.296s
sys     0m0.008s


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
  • Last Edit: 17 October, 2008, 12:59:19 AM by xmixahlx

  • m0rbidini
  • [*][*][*]
Informed rebuttal of VBR disadvantages appreciated
Reply #33
Quote
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.


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?

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


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.

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


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

  • Lyx
  • [*][*][*][*][*]
Informed rebuttal of VBR disadvantages appreciated
Reply #34
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.
  • Last Edit: 17 October, 2008, 08:29:55 AM by Lyx
I am arrogant and I can afford it because I deliver.

  • pdq
  • [*][*][*][*][*]
Informed rebuttal of VBR disadvantages appreciated
Reply #35
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.

Informed rebuttal of VBR disadvantages appreciated
Reply #36
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!
  • Last Edit: 17 October, 2008, 09:15:42 AM by Slipstreem

  • Synthetic Soul
  • [*][*][*][*][*]
  • Global Moderator
Informed rebuttal of VBR disadvantages appreciated
Reply #37
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.
I'm on a horse.

  • halb27
  • [*][*][*][*][*]
Informed rebuttal of VBR disadvantages appreciated
Reply #38
Why have a long discussion when it all can be summed up with one image: ...

Great image, it really sums things up.
lame3995o -Q1

  • pdq
  • [*][*][*][*][*]
Informed rebuttal of VBR disadvantages appreciated
Reply #39
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.

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!"

  • lvqcl
  • [*][*][*][*][*]
  • Developer
Informed rebuttal of VBR disadvantages appreciated
Reply #40

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

Great image, it really sums things up.

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)
  • Last Edit: 17 October, 2008, 09:51:40 AM by lvqcl

Informed rebuttal of VBR disadvantages appreciated
Reply #41
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. 
  • Last Edit: 17 October, 2008, 10:03:19 AM by Slipstreem

  • Lyx
  • [*][*][*][*][*]
Informed rebuttal of VBR disadvantages appreciated
Reply #42
Quote
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...

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)
  • Last Edit: 17 October, 2008, 10:30:12 AM by Lyx
I am arrogant and I can afford it because I deliver.

Informed rebuttal of VBR disadvantages appreciated
Reply #43
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. 
  • Last Edit: 17 October, 2008, 10:44:06 AM by Slipstreem

  • Lyx
  • [*][*][*][*][*]
Informed rebuttal of VBR disadvantages appreciated
Reply #44
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.

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.

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

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
I am arrogant and I can afford it because I deliver.

  • halb27
  • [*][*][*][*][*]
Informed rebuttal of VBR disadvantages appreciated
Reply #45
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.
  • Last Edit: 17 October, 2008, 11:05:32 AM by halb27
lame3995o -Q1

  • greynol
  • [*][*][*][*][*]
  • Global Moderator
Informed rebuttal of VBR disadvantages appreciated
Reply #46
Now we're just going around in circles.  There was a reason why the presets were scrapped in favor of a simpler system.
13 February 2016: The world was blessed with the passing of a truly vile and wretched person.

Your eyes cannot hear.

  • Lyx
  • [*][*][*][*][*]
Informed rebuttal of VBR disadvantages appreciated
Reply #47
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).
  • Last Edit: 17 October, 2008, 11:23:24 AM by Lyx
I am arrogant and I can afford it because I deliver.

  • Synthetic Soul
  • [*][*][*][*][*]
  • Global Moderator
Informed rebuttal of VBR disadvantages appreciated
Reply #48
We're also going way off-topic...
I'm on a horse.

Informed rebuttal of VBR disadvantages appreciated
Reply #49
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.