|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
152.163.100.7
In Reply to: No, PPCM is the same as MLP. posted by Charles Hansen on September 26, 2005 at 19:10:22:
I just didn't know the different nuances between LPCM and MLP/PPCM.
Follow Ups:
At least that's the premise. MLP/PPCM as a lossless algorithm should technically give out exactly what it got in. It's the same flavor of CODEC as FLAC, ALAC, and Monkey's Audio. (All of which, by the way, are more efficient than MLP, at least in stereo.)I'm not going to even touch on arguing the 'differences between MLP and DSD' - that's not an appropriate comparison. DSD has a similar lossless packing schema called DST; MLP is a compression method, not a modulation or encoding method.
So the result is still PCM. LPCM is rather wasteful and has a lot of redundant data. Especially, for example, during absolute silent passages, you're storing a run-length of zeroes that could be packed into a dictionary and pattern-repeated.
Again, in its most basic, if you put 110001101 PCM into MLP, you should get 110001101 out. However there are some caveats.
There's an option in MLP to use their ReBit (yes, (TM)) algorithm. This 'watches' the dynamic range of a given block and reduces bit depth accordingly: supposedly it will never reduce the effective bit depth to any lower than is actually used by the audio, but in a world of DACs and ADCs with widely varying noise floors, I'm not so sure what this means. One "rule" of ReBit, however, is that it will never reduce the bit depth to below 16 bits, under any circumstances.
ReBit is optional, and its savings are, in my opinion and experience, negligible. A three-odd minute stereo track at 192/24 will compress from 250mb in LPCM to 165mb in PPCM(MLP) without ReBit. Of course, depending on the characteristic of the signal, this would vary, but on good days the best I've seen is 155mb on that same track when using ReBit at its maxiumum.
Now, of course, there's a savings increase with multichannel since you have a few more dimensions of redundancy to work with. (Similar to why 448kbps Dolby Digital 5.1 is not the equivalent, channel per channel of, say, Dolby Digital 2/0 @ 148. You have M/S matrices to deal with and in general a 5.1 signal will yield a higher ratio of compression than a 2/0 signal.) The rear channels can be given more ReBit latitude than the front and center channels. So in a conservative mix you could see Ls and Rs and C running at 96/16 almost full time, and Lf and Rf running at 96/24 or a minimum of 96/20, selectable in the encoder.
Again I'm not so sure about the intelligence of the MLP encoder when it comes to applying ReBit, so in that sense you could posit an argument that MLP is not truly lossless when this option is used.
But, without it, you're just talking about entropy and dictionary encoding which should not touch the sound or even the resultant decoded LPCM in any way shape or form. In theory you should be able to take a 250mb LPCM wav, run it through MLP and create a 165mb MLP file, decompress that MLP back to WAV, and the resultant LPCM file and original LPCM file should be bit-for-bit identical.
But it's all PCM. Comparing it to DSD is like comparing .ZIP to .JPG... they operate in different domains.
> > Comparing it to DSD is like comparing .ZIP to .JPG... they operate in different domains < <Not quite. A JPEG is usually already compressed to the max (which is why it's used so much over the internet).
Just try zipping a JPEG -- the resultant 'ZIP' file is usually not much different in size to the JPEG.
But if you zip a raw .BMP bitmap, then you get significant file-size reductions. So, a BMP is analogous to LPCM and DSD etc.
But a .ZIP file is analogous to MLP and DST etc.
AND, a JPEG is also analogous to MLP & DST, since all three are compressed 'packages', which contain a 'payload'.
And if you zip a JPEG, then you are in effect trying to compress the payload twice.
JPEG is not analogous to MLP and DST. JPEG is lossy. JPEG is analgous to MP3. As I said, MLP is analagous to FLAC and ALAC. I know damn well that ZIP is dictionary/entropy compression (mitigation of redundancy) as is MLP and DST.
The point I was trying to make is the same one you were trying to make, that comparing MLP to DSD is apples and oranges.But, you've got compulsive asshole syndrome, probably because I've listened to a SACD some time in my life.
> > probably because I've listened to a SACD some time in my life. < <Paranoid or what? I wasn't even talking about that.
JPEG IS a payload carrier. Just like a zipfile. Granted, in the case of JPEG, the payload is lossy -- depending on the level of compression selected when you save the file. But then it's compressed for portability. A different thing altogether.
> > Re: Gee, thanks for schoolin me, massa! < <
Michi, a bit of friendly advice: This really is the wrong forum for inane Jar-Jar impersonations. There are plenty of geek forums for that, though. And I'm sure they'd welcome you with open flappy ears.
You think that was a "Jar-Jar" imitation? Yeah. Star wars used the term "massa'". You got it.Friendly fucking advice my ass, Martin. You just can't stand not showing a thing or two to someone who isn't as privilege and old as yourself.
You can split hairs, and oh for god sakes I know you will: The JPEG specification includes a container *AND* DCT compression (or just raw entropy encoding at the 'lossless' setting) to act on the image it's carrying.
You know damn well what I was trying to get across, you just couldn't resist the masturbatory satisfaction of poking holes in what wasn't a complete and watertight thesis when making a comparison between MLP and DSD.
My original point was that MLP cannot be compared to DSD, because it's not a modulation method.
Oh and, please tell me, what the fuck gives you the position and right to tell me where to go on these forums?
Please don't use the term "friendly advice". You're a liar. You're no friend of mine, so lay it out like it is: adversarial advice.
> > Oh and, please tell me, what the fuck gives you the position and right to tell me where to go on these forums? . . . Please don't use the term "friendly advice". You're a liar. You're no friend of mine, so lay it out like it is: adversarial advice. < <You've really lost the plot. Ever heard of sarcasm/irony? It's just lost on some people. You are one of them.
You may reply with more irrational expletives if you so wish. That is your right. However, it does not impress. Really.
I asked earlier but I think the post disappeared thanks to Chris' housekeeping.
From your description, ReBit does not sound to be perfectly lossless. Is that true? Is there a way we can find if our discs are encoded using ReBit? I would be disappointed to find some of my discs to have used lossy ReBit when I assumed all the while that it was loss-less because it was MLP!
So which bits its losing and why and when, that's not something that is going to be readily available. We're told it's adaptive, and won't go below 16 bits. Or you can set a hard limit minimum, per channel, anywhere between 16 and 23 bits.Again, not every recording uses it because it isn't mandatory. By default, from what I can see, the encoder has it off. But since it's encoded in the stream and not flagged, there's no real way to tell if a particular MLP track has been "re-bitted".
Theoretically, it could be "lossless" in that it simply truncates unused zeroes. But I don't think that's how it works. If so, why would the encoder allow thresholds to be set? If it were still lossless, wouldn't it make the maximum-without-loss choice every time?
So I don't think ReBit is lossless. I certainly could do a quick encode and decode and compare if folks were interested. I'm not sure how cool Meridian would be about that though. I wonder if there's any language like that in the licensing agreement. I'd hope not. I'll have to look at that, too, but I don't see how a compare would be a breach of that.
Right from the horse's mouth..."The ReBit process reduces the effective bit-depth of selected channels by resetting the Least-Significant Bits (or LSB - the 24th bit, the 23rd bit, etc.) to zero, either manually or automatically, in 2-bit steps. This reduces the amount of data compression necessary to encode the channel, without reducing the actual number of bits (which is why this is known as "effective bit-depth reduction"). The significance of this is that if the DVD-A player has a "24-bit" indicator, it will stay lit.
ReBit is a "lossy" process, because it reduces the actual bit-depth resolution of one or more channels before encoding (the MLP encoding process itself remains Lossless). If the source material has failed the encode process, the original soundfiles must be altered or be removed from the DVD-Audio disc. In these rare cases, ReBit is an effective solution. "
Luckily it looks like it was desinged as a last resort and most folks probably aren't going to be using it arbitrarily.
I've never had an MLP FIFO failure so I've never had to turn the damn thing on.
... ReBit + Verance ... I dont know... Neither are mandatory. I guess it comes down to 'let your ears be the judge'. I'd have to wonder what Verance at top strength and ReBit at full latitude would really sound like compared to the original. That's another test we could do. (I have access to the Verance encoder as well) A -> verance -> ReBit -> B, compare.
I dont like that one clause though: "The significance of this is that if the DVD-A player has a "24-bit" indicator, it will stay lit." Hurrah for that, I guess.
Rebit's purpose is to save space when 24 bits are not needed in one or more channels.In a multichannel recording where the rears are mostly used to record the ambiant sound then the dynamic range in these channels is fairly limited aleady. So re-bit can save some space if the dynamic range isn't used to the full extend. In such a scenario it's perfectly lossless. (A bitcheck of these track easily confirms how many of the bits are actually used.)
The 'keep the 24 bit indicator lit' is just half the story. By padding the decoded word up to 24bits in the MLP decoder the design of the subsequent filter/dac design simpler.
Note that this option helps out with the current limitations of the DVD format.
The other end of the scale of MLP's capabilies is that it can encode up to 63 channels at 24/192ks perfectly lossless.
.
..or absolutely inflammatory at any cost to anyone who may tarnish the jewel of the "team" you cheer for?Nothing I said wasn't factual. But you had to come by and snipe because you know I've listened to SACD and not pissed on it in my time here.
REBIT IS THERE. *MERIDIAN* HAS SAID IT IS LOSSY. But you're more of an authority on MLP than Meridian is I guess.
I suspect there are other reasons that you feel you have a duty to kick dirt on my posts, but that's more of a personal issue.
"In our MLP training information, we point out as a matter of information that the size of a compressed file can be adjusted by using (gentle) low-pass filtering or selection of a word size to suit the project. This is useful background information to a certain type of producer, who may want to free up space on a disc for other assets or simply understand how the process works."
"Gentle" prefiltering? So what? ReBit *IS* LOSSY. Prove otherwise, you big-headed twerp.I guess "Gentle" is now also "Lossless". Oh, no no I know, the MLP process (when not using ReBit) is still lossless - but we'll just *ignore* the fact that a LPF had to happen in order to make MLP more efficient.
Agree to disagree, bury the hachets, whatever, but we're degenerating into name calling and I don't want to close this thread like the one above.
.
This is what: ReBit affects "bit depth". And the article refers to "word size" -- i.e. "bit depth" -- as a factor affecting compressability. Now you can do that within MLP, or you can do it elswhere in the production chain. Adding an optional function to MLP doesn't make it bad. It merely makes it more 'flexible'.> > Gentle" prefiltering? So what? ReBit *IS* LOSSY. Prove otherwise < <
You are saying rebit is lossy. But I am saying MLP -- sans ReBit -- is lossless. I think we agree on both scores.
And you do puzzle me with this loaded statement:-> > LPF had to happen in order to make MLP more efficient. < <
But who in the industry, with practical knowledge of DVDA, has ever proclaimed that MLP is "inefficient"?
Anyway, we now know that these sorts of tricks do apply to SACD, i.e. in order to extend a full six-channel program to more than 65 mins, reducing the dynamics allows the DST compressed file to still fit into the available disc space of a hybrid SACD. That's not rocket science.
Martin said: "Anyway, we now know that these sorts of tricks do apply to SACD, i.e. in order to extend a full six-channel program to more than 65 mins, reducing the dynamics allows the DST compressed file to still fit into the available disc space of a hybrid SACD. That's not rocket science.This is totally WRONG and in a previous deleted post he even said Audiophile companies do it. NO SACD I know of has been released that does not have the full dynamic range of the DSD master tape. Please Martin give as the titles so they can be check out!
Here are the choices taken so far to increase playing time for Multi-Channel programs over 74 minutes. 1) Use 4.0 or 5.0 channels instead of 6.0 to gain extra playing time or 2) release the longer program on 2 SACDs instead of 1 SACD. The first option was used by Telarc for example and the second option is used by Universal and many others.
This quote was given to Martin by an unnamed SACD engineer for an audiophile company and just like his quote that SACD is a virus, I believe this came purely from Martin own head.
Martin says "it's not rocket science" that is true because it is NOT done.
.
This post is made possible by the generous support of people like you and our sponsors: