HydrogenAudio

Lossy Audio Compression => MP3 => MP3 - Tech => Topic started by: Moon on 2008-10-16 09:54:42

Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Moon on 2008-10-16 09:54:42
As already mentinend in this thread (http://www.hydrogenaudio.org/forums/index.php?showtopic=66277&st=0&gopid=591767&#entry591767) some fanboy over at the offical Pioneer forums is making claims that VBR sucks (here (http://forums.pioneerdj.com/eve/forums/a/tpc/f/5971012904/m/9631066014?r=9731066014#9731066014) and here (http://forums.pioneerdj.com/eve/forums/a/tpc/f/8191012904/m/5461038435?r=7601078435#76010784359)) 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!
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Raiden on 2008-10-16 10:51:27
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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: halb27 on 2008-10-16 11:27:29
It's all up to whether an encoder works well. Good VBR encoders like Lame 3.98, Nero AAC, Vorbis work fine.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Jens Rex on 2008-10-16 11:43:30
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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Slipstreem on 2008-10-16 12:56:15
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...
Quote
Unlike other MP3 encoders which do VBR encoding based on predictions of output quality, LAME's default VBR method tests the actual output quality to ensure the desired quality level is always achieved.
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 (http://ftp://ftp.tnt.uni-hannover.de/pub/MPEG/audio/mpeg1/compliance/) (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. 
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: probedb on 2008-10-16 12:59:18
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
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: add on 2008-10-16 16:40:50
Call me paranoid, but it worries me to see the words "Pioneer National Trainer // Product Specialist" in his signature.


My thoughts exactly.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: ExUser on 2008-10-16 16:59:19
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!
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Synthetic Soul on 2008-10-16 17:08:34
I responded to the second, newer thread.
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 (http://forums.pioneerdj.com/eve/forums/a/tpc/f/5971012904/m/9631066014?r=5801096014#5801096014) 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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Lyx on 2008-10-16 17:19:49


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


My thoughts exactly.

I'm not surprised. A title in nowadays industry doesn't mean much regarding competence.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: ExUser on 2008-10-16 18:10:33
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:
Quote
that's plenty of space saving for me, since 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'm going to mull this over a bit and respond sometime this evening... what nonsense.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Slipstreem on 2008-10-16 18:18:38
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. 
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Soap on 2008-10-16 18:59:28
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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Slipstreem on 2008-10-16 19:39:27
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. 
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: uart on 2008-10-16 20:01:04
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.


Quote
Basic lesson in computing: ALL instructions and data to be operated upon must exist in RAM. If the instruction or data is external to the RAM, the system must first copy it into RAM (from wherever - Hard Disk, CD, whatever) before it can be used by the CPU. The CPU has no direct access to the hard drive (or, in the case of the CD player, the CD), it must go through the RAM. The CPU also has to actually execute the copying of things into RAM (which in reality is actually handed off to the chipset in the machine, but the chipset won't operate on anything unless it is told to do so by the CPU).

So, as each frame is read to be decoded, it is copied into RAM (quite probably more than one frame at a time, however).

What happens (in an oversimplified manner) is this: the processor that is decoding the frame is dumb. It doesn't know where the frame ends, it just keeps operating on streams of data - possibly operating into some area of the memory that contains something else that isn't MP3 data. This is known as buffer overflow, and can cause crashes and/or bad sounding music playback. This is prevented by setting something called a buffer size - it knows how much data it must read before stopping.

If every frame that is copied into RAM to be operated on is a different size, the CPU needs to be told of this, executing an extra instruction that sets its buffer size. This means that every frame needs at least 2 operations to work - the buffer set, and the buffer read/operate. In a particularly variable MP3, for example, where the frame size is changing A LOT from one to the next, the CPU can't read nearly as much data "ahead" because it never knows where the end will be, and it might read too far before the memory is copied (because a CPU operates many many times faster than the hard drive, or CD, can write data to the RAM) and hit a buffer overflow, causing issues of unknown result. Also, since the CPU is in charge of ALL the RAM and is also doing other things (both in a CD player and in a normal computer), every time it resizes the RAM buffer (because it's copying frames of varying sizes), it might copy something to the area that was occupied by a larger frame but is now free before it needs to use it for audio data again. Now, if it needs to fill that space with audio data (because splitting up a frame in memory would be very bad), it has to MOVE what's there before it can copy new data into that space. This eats up time and processor resources.


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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: ExUser on 2008-10-16 20:03:18
Who is BDX?
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: uart on 2008-10-16 20:06:21
I dont know, it's not me. Does anyone have a transcript of exactly what he said to banned anyway?
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Slipstreem on 2008-10-16 20:12:55
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. 
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: kornchild2002 on 2008-10-16 20:48:01
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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: DJRyanJ on 2008-10-16 20:49:04
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-
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: ExUser on 2008-10-16 21:13:07
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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: halb27 on 2008-10-16 21:29:07
...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. ...
...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 ...

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: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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: kwanbis on 2008-10-16 21:36:21
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.

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.

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

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

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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: m0rbidini on 2008-10-16 21:57:13
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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: DJRyanJ on 2008-10-16 22:00:44
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.

Quote
Is it that hard nowadays to properly support the standard?


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.

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

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


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.

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


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

Quote
...wrote a lot of fancy stuff about VBR's speed penalty which is really nonsense. And with respect to quality you put the blame on VBR for no really existing reason.


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

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


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-
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Ron Jones on 2008-10-16 22:59:04
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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: [JAZ] on 2008-10-16 23:01:38
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...)
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Axon on 2008-10-16 23:02:56
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...
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: m0rbidini on 2008-10-16 23:32:34
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).
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: kwanbis on 2008-10-17 03:09:10
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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: DJRyanJ on 2008-10-17 04:39:33
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-
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: kwanbis on 2008-10-17 05:06:19
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).
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: xmixahlx on 2008-10-17 05:52:57
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/ (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/IriverRuntime)
http://www.rockbox.org/twiki/bin/view/Main...manceComparison (http://www.rockbox.org/twiki/bin/view/Main/CodecPerformanceComparison)

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
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: m0rbidini on 2008-10-17 11:00:18
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
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Lyx on 2008-10-17 13:21:23
Why have a long discussion when it all can be summed up with one image:

(http://img511.imageshack.us/img511/8918/lamewv3.png)

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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: pdq on 2008-10-17 13:50:08
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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Slipstreem on 2008-10-17 13:57:31
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!
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Synthetic Soul on 2008-10-17 14:04:39
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 (http://www.hydrogenaudio.org/forums/index.php?showtopic=66564), 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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: halb27 on 2008-10-17 14:33:10
Why have a long discussion when it all can be summed up with one image: ...

Great image, it really sums things up.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: pdq on 2008-10-17 14:48:05
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!"
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: lvqcl on 2008-10-17 14:49:50

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)
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Slipstreem on 2008-10-17 15:01:25
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. 
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Lyx on 2008-10-17 15:13:21
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)
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Slipstreem on 2008-10-17 15:43:05
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. 
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Lyx on 2008-10-17 15:56:19
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
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: halb27 on 2008-10-17 15:59:43
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.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: greynol on 2008-10-17 16:05:32
Now we're just going around in circles.  There was a reason why the presets were scrapped in favor of a simpler system.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Lyx on 2008-10-17 16:21:58
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).
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Synthetic Soul on 2008-10-17 16:53:13
We're also going way off-topic...
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Slipstreem on 2008-10-17 19:25:42
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. 
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: DJRyanJ on 2008-10-17 20:59:06
I actually know Pulse personally and he's not nearly as much of an ass as he seems to be on the forums.  Unfortunately for us, we get a lot of people who don't read the rules (it's Pioneer's forum and it's their rules, some of which people don't like), so Pulse deals with a bit of a heavy hand. 

Anyway, back on topic here...

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


Excellent.  Thanks!  I've heard of MP3gain but never used it; I'll check it out.  Obviously since you did your own encoding, you wouldn't have come across the types of files I'm referring to (which I've been told via a nice PM that I can't do; sorry for the violation and I hope this isn't also crossing the boundary) which tend to be broken.  But trust me when I say, they're abundant.

@xmixahlx - excellent info, thanks for that.  Nice to see some concrete numbers.

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


You are correct sir.  I was trying to justify it and ended up deleting it because I clearly had not thought it all the way through.  I gotta stop doing that.

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


It's no secret that the CDJ's use a buffer to be able to manipulate the audio.  I actually tried one time to make a CD play backwards in a player (I turned the motor around - and it WASN'T a CDJ that I paid $1200 bucks for) - it didn't work.  LOL.  As to what digital magic is happening internal to the player, that's a trade secret, I'd assume.  There may be a valid reason for why VBR is not as supported as CBR - but I'm not privy to it.

Pioneer was one of the last hardware DJ companies to support MP3.  It was a major point of contention for a lot of people for a long time.  We never found out why it took them so long, but eventually support was released.  Perhaps the reason they don't support VBR "properly" is similar to the argument around Wavelab - Pio's products are aimed at "professionals" and for a long time it was assumed that they wouldn't use MP3's.  I'm not sure I agree with that, and it's speculation anyway, but it's an easy speculation to have I'd say.  The other possible reason it's not supported properly is because their support for it is so new, it's suffering from the same problems reported by many VBR implementations - lack of seek, difficulty reading it correctly, etc. etc.  Again, just speculation, and IMHO if VBR is as good as you're claiming (which I'm starting to believe), then there's no excuse for the lack of support.  Then again, the same could be said for their initial lack of support for MP3's at all.

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


I'd say that's true of VBR encoder settings that use the full range vs. CBR settings below 320kbps; it's NOT true of 320kbps, which is the max anyway and is what I use.  While at 320 it might be "wasting bits" on the uncomplex parts, the same could be argued for an uncompressed file - do we REALLY need all those bits to describe some minutia of the sound that we probably can't distinguish anyway?  Isn't the sonic quality presented by MP3 "good enough" for "most people"?  I'm sure you'd say no, but then we're right back to the same argument.

Quote
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


Don't worry about it.  I can see how easy it is to make these kinds of assumptions; thanks for the warm welcome.

-r-
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: kornchild2002 on 2008-10-17 21:21:00
I'd say that's true of VBR encoder settings that use the full range vs. CBR settings below 320kbps; it's NOT true of 320kbps, which is the max anyway and is what I use.  While at 320 it might be "wasting bits" on the uncomplex parts, the same could be argued for an uncompressed file - do we REALLY need all those bits to describe some minutia of the sound that we probably can't distinguish anyway?  Isn't the sonic quality presented by MP3 "good enough" for "most people"?  I'm sure you'd say no, but then we're right back to the same argument.


You are right that a VBR mp3 file, when compared to a 320kbps CBR mp3 file, is not true 320kbps.  That doesn't mean anything though as you are kind of arguing against yourself here.  320kbps is wasting bits on most samples for most people and you are somewhat right about uncompressed audio.  There aren't many people out there that benefit from uncompressed audio.  That is why we have lossless though.  Lossless formats such as FLAC and Apple Lossless are able to shave off 10MB or more from the file size (when compared to uncompressed WAV) while retaining track tag information and still being bit-for-bit identical.  The main reason behind having lossless/uncompressed audio is so that someone can have a perfect backup of their music.  They can then use only lossless files or use a lossy format.  You are right that mp3 is normally good enough for most people.  However, mp3 is normally good enough for most people at much lower bitrates.  320kbps is a "safe bet" but you don't need that high of a bitrate when encoding audio even for DJ purposes.  The environments where DJs often play are not really optimal for music.  The rooms are often not acoustically tuned, the positioning of the speakers are not optimal (studies have shown that even with small speakers, moving them by 1 cm can change the perceived quality), and people absorb and reflect the sound waves while adding to additional noise influences by talking and whatnot.  That is why one doesn't really need 320kbps.

So go ahead and argue that 320kbps is a safe bet (or that you need it as your ABX tests have shown that).  However, I wouldn't argue that that uncompressed audio uses more bits that needed and make that look bad and then come back saying that 320kbps uses more bits than needed and that is alright.

Edit:  It is nice to see someone who will listen to logic and not come off as a butt hole.  I am sure that Pulse isn't like that in real life and I know that maintaining a forum can add to daily headaches.  However, he was coming off as someone who refused to listen to logic and would just ban people who disagreed with them.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Neasden on 2008-10-17 21:34:06
On the switch subject, I just would like to add that the numbers should be inverted. That is, V1 to V9 (max. quality). I never understood why in the world "zero" was the best quality. The way it is it's simple, but quite confusing for newbies of course. Apologies that I went offtopic with others, but I believe that was a valid claim.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: DJRyanJ on 2008-10-17 21:40:58
320kbps is a "safe bet" but you don't need that high of a bitrate when encoding audio even for DJ purposes.  The environments where DJs often play are not really optimal for music.


Generally, you'll get no argument from me and I said as much in my first post.  What I DO argue however is that while DJ environments are never (or rarely optimal), I don't want to be the limiting factor, so I play the highest-quality music I can given the tools I use.

Quote
So go ahead and argue that 320kbps is a safe bet (or that you need it as your ABX tests have shown that).  However, I wouldn't argue that that uncompressed audio uses more bits that needed and make that look bad and then come back saying that 320kbps uses more bits than needed and that is alright.


I would never say such a thing!  LOL and if I did, then that's not what I meant.  I was arguing that SOME PEOPLE might say that uncompressed is pointless as it uses more bits for the same thing that people can't hear anyway.  I would rather use uncompressed; but the realities of what I do make that impossible (for now).

-r-
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: ExUser on 2008-10-17 21:48:04
...
[off-topic]Happy 1000th post! [/off-topic]
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Slipstreem on 2008-10-17 21:59:17
What I DO argue however is that while DJ environments are never (or rarely optimal), I don't want to be the limiting factor, so I play the highest-quality music I can given the tools I use.
On that basis, if you found out that that you couldn't tell the difference between a CD quality source and, say, the ~128Kbps LAME VBR in our listening tests, would you then reconsider your need for 320Kbps CBR?

It's difficult to say exactly what average bitrate is required in VBR to outstrip the acoustic requirements of the venues you play in and the speakers you use, but I think it highly unlikely that you need a constant 320Kbps in reality when VBR at around 175Kbps suffices on high-end home equipment through high-end headphones for many of us. Yes, even the fussy ones. LOL

As you say though, whether or not you can use such files with any degree of reliability will be determined by the player you use. Hopefully either yourself or Pulse will try some LAME generated VBR files on your Pioneer players to find out if the VBR problem really is a global one or if it's just limited to badly written or broken VBR files.

Cheers, Slipstreem. 
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: kornchild2002 on 2008-10-17 22:27:42
Generally, you'll get no argument from me and I said as much in my first post.  What I DO argue however is that while DJ environments are never (or rarely optimal), I don't want to be the limiting factor, so I play the highest-quality music I can given the tools I use.


Even if you use lower bitrate music (128kbps-160kbps), you won't be the limiting factor.  There are far too many factors that degrade the perceived sound quality of music let alone in a club/dance hall/whatever.  Also don't forget that you are playing music for an audience where the majority of people are fine with 128kbps WMA/AAC music from legal online stores.  Just know that the quality of music that the DJ uses if often the very last limiting factor amongst thousands of other factors.

I would never say such a thing!  LOL and if I did, then that's not what I meant.  I was arguing that SOME PEOPLE might say that uncompressed is pointless as it uses more bits for the same thing that people can't hear anyway.  I would rather use uncompressed; but the realities of what I do make that impossible (for now).

-r-


I must have misinterpreted your post.  I took the comment of "While at 320 it might be "wasting bits" on the uncomplex parts, the same could be argued for an uncompressed file - do we REALLY need all those bits to describe some minutia of the sound that we probably can't distinguish anyway?" the wrong way.  I took it as you saying that we have all this uncompressed music that we don't really need and that is bad (it wastes bits) but you will go ahead and use 320kbps which wastes buts but that is alright.  The use of uncompressed audio simply is not needed in a day where we have lossless codecs and high performing lossy codecs that can achieve transparency at such low bitrates (128kbps).  I suggest that you conduct a few blind ABX tests with your best set of headphones and Lame 3.98.2.  I think that will help you further understand what we are trying to say.

As Slipstreem said, most people are fine with Lame's -V 3 setting and this includes the "picky" people.  Lame has changed a lot over the years and the perception of "320kbps or bust" is no longer needed.  I had a roommate that continued to use MusicMatch for all their ripping needs and they would use 320kbps (MusicMatch uses the FhG mp3 encoder).  They said that anything below 320kbps CBR sounded like "crap" especially when using their stereo system.  I sat them down and had them conduct a blind ABX test using their headphones, using my theater system (which is much better than theirs), and then using their stereo system.  They failed to properly distinguish between a -V 5 encoded file and the source lossless file every single time.  Even after that, they refused to believe that I was using -V 5 files and still continued to rip with MusicMatch at 320kbps.

[off-topic]Happy 1000th post! [/off-topic]


I didn't even notice that.  Thank you!
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: DJRyanJ on 2008-10-18 01:11:35
On that basis, if you found out that that you couldn't tell the difference between a CD quality source and, say, the ~128Kbps LAME VBR in our listening tests, would you then reconsider your need for 320Kbps CBR?


I'm not ready to do that just yet, for a couple of reasons:

1) I occasionally remix the tracks I use, and while I'm no pro remixer, I try to maintain quality where I can.  When an uncompressed version is not available, I must use my MP3 copy, and in that respect having the highest possible original copy is best.

2) I don't have a problem with the amount of space that a 320kbps CBR takes vs. a VBR.  I've accepted the amount of space that a 320kbps CBR takes and I'm OK with it; if we can all agree that the point of MP3 is to save space, then likely everyone has a different level that they're willing to accept in terms of saved space.  Mine is currently at 320kbps.

3) I don't totally trust my ears.  That sounds ridiculous given the topic at hand, but just because I can't tell the difference doesn't mean someone else can't (or won't be able to in the future - my music collection is also designed to last a long time).

Given those reasons, if someone could conclusively prove that VBR not only saved space over a 320kbps CBR but ALSO provided CONSISTENTLY better sounding files, then I'd be the first to switch over, as long as the program I use to play back with supported them.

Even if you use lower bitrate music (128kbps-160kbps), you won't be the limiting factor.  There are far too many factors that degrade the perceived sound quality of music let alone in a club/dance hall/whatever.  Also don't forget that you are playing music for an audience where the majority of people are fine with 128kbps WMA/AAC music from legal online stores.  Just know that the quality of music that the DJ uses if often the very last limiting factor amongst thousands of other factors.


I know this is true; and you forgot something: the sheer drunkenness of the crowd  .  But just because the general public accepts that level of quality doesn't mean that I should.  In my opinion this is one of the fundamental wrongs with the online music idea (and, in some ways, society in general - but this is hardly the forum for that  ); few seem to care about quality and are willing to accept things as being "good enough".

The use of uncompressed audio simply is not needed in a day where we have lossless codecs and high performing lossy codecs that can achieve transparency at such low bitrates (128kbps). ... I think that will help you further understand what we are trying to say.


This may be true.  And I do understand what you're trying to say; but until the day when we see wide-spread adoption of these lossless codecs as well as a wide-spread knowledge of the way to PROPERLY encode things with those high performance lossy codecs, then I think we may be stuck with the "evils" of uncompressed audio 

As for me, as mentioned above, while I may not be able to tell, and you may not be able to tell, and VBR may be good enough for me, I'm just not quite ready to accept it.  However, that in mind, I will continue to experiment, monitor, and otherwise expand my mind and opinions.

I will not, however, be spreading lies about VBR any longer, and will in fact promote them to appropriate people.

-r-
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Synthetic Soul on 2008-10-18 10:00:57
I'm not ready to do that just yet, for a couple of reasons:

1) I occasionally remix the tracks I use, and while I'm no pro remixer, I try to maintain quality where I can.  When an uncompressed version is not available, I must use my MP3 copy, and in that respect having the highest possible original copy is best.

2) I don't have a problem with the amount of space that a 320kbps CBR takes vs. a VBR.  I've accepted the amount of space that a 320kbps CBR takes and I'm OK with it; if we can all agree that the point of MP3 is to save space, then likely everyone has a different level that they're willing to accept in terms of saved space.  Mine is currently at 320kbps.

3) I don't totally trust my ears.  That sounds ridiculous given the topic at hand, but just because I can't tell the difference doesn't mean someone else can't (or won't be able to in the future - my music collection is also designed to last a long time).
Some extremely valid points.

This topic seems to have meandered quite a bit, and it's been interesting in part.

I would like to point out that personally I have no issue with someone choosing to use 320kbps CBR.  I do have an issue with people using FUD to stop people using VBR, or lower bitrate files, when they may actually be completely suitable for them, and more ideal than 320kbps CBR.

In essence, the software cannot handle VBR, and that is a failing of the software.  Trying to negate that failing by saying that people who use VBR or sub-320kbps CBR files are fools is just really, really, wrong.  Pulse should stick to what he knows.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Moon on 2008-10-18 11:11:37
Well, I'm sorry but after finding out (http://www.hydrogenaudio.org/forums/index.php?showtopic=66277#) about Pioneer's VBR limitation my frustration with apparently flawed development processes of huge companies got the best of me (again). People on my blog keep reminding me of workarounds (most of which I'm already aware of) but it's the fact that I need a workaround (like with my Sony (http://blog.techflaws.org/2008/06/19/sony-cdx-gt414u-car-mp3-cd-player/)) that's ticking me off in the first place.

So when I saw the way the argument goes on the Pioneer forums I wanted someone with knowlegde about the technical issues set the record straight. My opinion is this:

a) a full-fledged MP3 player has got to be able to work with VBR or be renamed
b) properly encoded VBRs are in no way inferior to CBR

Since Pulse as a regular seemed to be leading the discussion on VBR over there with opinions rather than facts I was afraid some Pioneer developers might take this for granted and shun the idea of properly implementing VBR support in future hardware.

It appears to me that Pioneer has gotten it all wrong. It's similar to what's going on at the moment with DVD standlones and USB support. Since USB-HDDs use the same protocol as USB sticks those players can playback media from HDD as well. But some 2.5" HDDs draw more power from the slot than the 500 mA specified so they can't gurantee them to work which simply makes them say it's not possible. Pioneer's hardware does playback VBR but it's officially not supported, you cannot seek in those files and you don't get the remaining time (both vital for a DJ).

So I would expect them to properly implement support for VBR while at the same time making it clear in the manual that this applies only to properly encoded files (proper seek index and stuff). Of course one would have to check playback of each file prior to public performance which I would do even for my own encodes.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Slipstreem on 2008-10-18 13:04:11
With reference to your last paragraph, have you tried playing a file generated with LAME in VBR with just the -V switch? To the best of my knowledge, this should produce an ISO/IEC compliant file. Maybe a LAME developer could verify that for me?

Cheers, Slipstreem. 
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Moon on 2008-10-18 16:36:13
I'm gonna try em tonight. I've also converted some files I'd encoded from my own CDs on --preset standard with mp3packer on AUTO bitrate resulting in all files blown up to 320 kbit/s CBR. Is there a way to encode to the max frame used in the original VBR?
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Synthetic Soul on 2008-10-18 19:04:24
Well, I'm sorry but ...
I can't work out whether this is in response to my post.

As I say, I totally agree that the Pioneer should be fixed, so that it can use VBR properly.

Unfortunately, with mods like Pulse in that forum, I don't hold out much hope for you changing anyone's opinion, as he is likely to just respond to any post calling it into question with some crap that looks authoritative to other less-knowledgeable members.

Edit: Oh, and I thought mp3packer did just use the highest bitrate in the VBR file, not necessarily 320kbps.  I've only played with it though.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: pdq on 2008-10-18 22:16:28
If even a single frame uses 320 kbps then the entire file must, after repacking. The only exception would be if more efficient use of the bit reservoir allowed a 256 kbps frame to be used.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Moon on 2008-10-19 09:24:12
I can't work out whether this is in response to my post.

Nope, I wasn't addressing anyone in particular, just felt the need because I started all this fuss

If even a single frame uses 320 kbps then the entire file must, after repacking.

D'oh, of course 

Still, some tracks increased by 53% which is a lot. I've also tried LAME with the -V option and it doesn't make a difference to Pioneer: you can't seek and don't have the remaining time.

BTW, this manual entry could easily be adjusted to a VBR disclaimer for future models with proper VBR support:
Quote
MULTI READ
Supports playback of CD-R and CD-RW discs. (Some discs may not replay properly, however, due to certain special characteristics of some discs and recorders, as well as due to dirty or damaged discs.)
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: DJRyanJ on 2008-10-19 10:33:09
a) a full-fledged MP3 player has got to be able to work with VBR or be renamed


I don't entirely agree, at least in this context, because:

The Pioneer CDJ decks are NOT MP3 players anyway - they just happen to play MP3's AS WELL AS normal audio CD's.  That's not what they were truly designed for, it's just an added feature.

Since Pulse as a regular seemed to be leading the discussion on VBR over there with opinions rather than facts...


I think that Pulse's opinions were valid for what he knew.  While I agree with:
Quote
Pulse should stick to what he knows.

He did know what he was talking about, even if it was outdated.  I'm sure we can all agree that realistically, one bad experience can be enough to turn us off of something for a long while to come.  He's not perfect, just like any of us, so his "opinions" were "facts" - in my opinion (lol); they were just outdated.

Unfortunately, with mods like Pulse in that forum, I don't hold out much hope for you changing anyone's opinion...


I suggest you go and take a look at the current discussion.  Pulse has admitted that he has much to learn and is willing.

-r-
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Synthetic Soul on 2008-10-19 11:54:47
I suggest you go and take a look at the current discussion.  Pulse has admitted that he has much to learn and is willing.
All he needs to do now is actually act on it.  In his last post he still shows complete contempt for 128kbps MP3 files, and the MP3 format in general.

I think the roles played by yourself and the other moderator may have had a large influence in the "humility" of his later response.  We'll see.

At least djjay has suggested that the question will be raised with Pioneer; so I was, gladly, wrong on that count.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: kwanbis on 2008-10-19 19:25:49
Lossless formats such as FLAC and Apple Lossless are able to shave off 10MB or more from the file size (when compared to uncompressed WAV) while retaining track tag information and still being bit-for-bit identical.

Lossless compress to about 60% of a WAV size on average (iirc). Some things compress to 50% (half the size of the original WAV).
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Moon on 2008-10-20 09:50:24

a) a full-fledged MP3 player has got to be able to work with VBR or be renamed

I don't entirely agree, at least in this context, because:

The Pioneer CDJ decks are NOT MP3 players anyway - they just happen to play MP3's AS WELL AS normal audio CD's.  That's not what they were truly designed for, it's just an added feature.

That's not how they're advertized (http://www.pioneer.de/de/products/44/106/462/CDJ-200/index.html) (in Germany anyway) which is why I stand by my opinion. Roughly translated:

Quote
The ProDJ CD-Deck combines key elements of the Pioneer CDJ-Players with a host of brandnew functions like a full-fledged MP3-Player, Hot Loop, Beat Loop und our unique Loop Cutter...


The english page (http://www.pioneerelectronics.com/PUSA/Products/ProDJ/TabletopPlayers/CD+Players/CDJ-200) states:
Quote
Plays MP3s
* MPEG-1: Supports Audio Layer-3 sampling frequency 32kHz, 44.1 kHz, 48 kHz, Bitrate 32 Kbps ~ 320 Kbps.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: shadowking on 2008-10-20 12:50:33
Dj's of the world please stop bothering us with FUD because your decoders are BROKEN .
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: DJRyanJ on 2008-10-21 19:58:25
I'm trying to do some comparisons, and I'm looking for castanets.wav as it seems to be the one to test with.

I've searched this forum and come up with many links, unfortunately most of them are either down or have dead files.

Can anyone provide me with a working link to castanets.wav?  And if you're being generous, any other sound samples I should test things out with?

Thanks.

-r-
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: ExUser on 2008-10-21 20:16:34
http://ff123.net/samples.html (http://ff123.net/samples.html) is a good place to start. It refers to the LAME problem samples page for castanets.wav, which no longer exists. However, castanets.wav exists at http://ccrma-www.stanford.edu/~bosse/ (http://ccrma-www.stanford.edu/~bosse/) apparently.

Castanets is a good sample because it provides a clear example of pre-echo. Other killer samples for pre-echo which may be familiar to you as a DJ are Kalifornia by Fatboy Slim and Four Ton Mantis by Amon Tobin. Specifically, listen to the percussion in Four Ton Mantis and the distorted vocal sample in Kalifornia.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: halb27 on 2008-10-21 20:25:31
On problemSamples folder (http://home.arcor.de/horstalb/problemSamples) you'll find those samples I care about, including castanets.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: DJRyanJ on 2008-10-21 20:58:15
However, castanets.wav exists at http://ccrma-www.stanford.edu/~bosse/ (http://ccrma-www.stanford.edu/~bosse/) apparently.


Actually, castanets.wav is listed there but when I try to download it I get a 345 byte file.  Definitely NOT the proper file .

@halb27: Thanks for the link.

I'll search out those other tracks; I haven't heard them personally but that's alright.  I'm going to search my collection for some other "problem tracks" as well and see what I can come up with.

I'm planning a rather epic post over at the Pioneer forums with my own sets of data, samples, and trials to try to clear up any FUD that has been spread, as well as to (hopefully) kick Pioneer's ass a little bit in terms of fixing their VBR support (if that's what the data shows, which I'm sure it will).

Once it's posted I'll link to it here.

This may be a stupid question, but since it's relevant I'll ask it anyway: if I zip (or rar) the samples purely for the purposes of having a single file to download for the members (which I'm sure will include whatever mild amount of compression WinRAR can achieve), will this affect the quality of the unzipped/rared samples?  I assume no, because encoding something like a binary would necessitate lossless compression.  However, I just want to make sure I don't shoot myself in the foot before I start.

Thanks.

-r-
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: lvqcl on 2008-10-21 21:09:36
Quote
It refers to the LAME problem samples page for castanets.wav, which no longer exists.


http://lame.sourceforge.net/download/samples/ (http://lame.sourceforge.net/download/samples/)
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: ExUser on 2008-10-21 21:26:18
http://lame.sourceforge.net/download/samples/ (http://lame.sourceforge.net/download/samples/)
Great, thank you.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: halb27 on 2008-10-21 22:06:57
.. f I zip (or rar) the samples purely for the purposes of having a single file to download for the members (which I'm sure will include whatever mild amount of compression WinRAR can achieve), will this affect the quality of the unzipped/rared samples? ...

Zipping/unzipping (resp. using WinRAR) is a lossless process no matter what contents is zipped.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Moon on 2008-10-21 22:28:31
I'm planning a rather epic post over at the Pioneer forums with my own sets of data, samples, and trials to try to clear up any FUD that has been spread, as well as to (hopefully) kick Pioneer's ass a little bit in terms of fixing their VBR support (if that's what the data shows, which I'm sure it will).

Or at least in terms of fixing their product's advertising so they don't promise something they just don't deliver. Thanks.
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: Slipstreem on 2008-10-22 00:52:42
I'll search out those other tracks; I haven't heard them personally but that's alright.  I'm going to search my collection for some other "problem tracks" as well and see what I can come up with.
Bear in mind that your group of samples should also contain a fair representation of non-problem samples. Just focusing on problem samples gives a totally unfair representation of an encoders true performance as the vast majority of content will present no problem at typically recommended VBR -V values.

Cheers, Slipstreem. 
Title: Informed rebuttal of VBR disadvantages appreciated
Post by: DJRyanJ on 2008-10-22 04:31:00
That's the plan, slipstreem.

Moon, I'll see what I can do.

-r-