>In LAMP 5.0, dither is no longer a plug-in, and I'm not sure I'm >thrilled about that change (actually, I'm quite sure that I'm not >thrilled.) > >What's the reasoning behind this change? Also, during a bounce >the file first seems to be written, then dithered. Does that >mean first a 24bit file is created, then it's dithered down to >16bit? First of all, you are confusing dithering with truncating. Truncation is the process of reducing the bit depth & thereby throwing away some resolution. Dithering is the process of compensating for the resolution loss using fancy lowest-bit-twiddling algorithms. These steps can be performed in either order, but given what Logic is doing, I would guess that it writes the initial file at the truncated bit depth & then dithers. Logic might process that file or it might create a second temporary file, so I wouldn't assume that a second temporary file is being created without checking first (easy enough, watch your disk usage). And I definitely wouldn't assume that Logic renders a file at 24 bits first & then truncates a second file, that would be really wonky... >b) since it's no longer a plug in, it's no longer possible to quickly > switch dither during playback, to audition which dither works > best with a track Yeah, I agree, this is what I really don't like about the change. I definitely don't have the patience to render 3 mixdowns & then compare them all to see which worked best, so I wind up just using option #1 each time. It would be WAY preferable to have the option to compare in realtime. >What's the advantage of the new method? Absolutely nothing so far as I can see. My only guess is that maybe since Emagic are licensing the algorithm, it was delivered in a manner that could not be integrated into Logic's realtime internal processing system. That's all I can guess, because otherwise this is a totally lame approach. You know how people here debate about realtime bounces vs. the option for offline bounces? Well now we get both, & as a result the worst of both worlds! Some things get bounced in realtime & then others things happen offline afterwards. So you still can't bounce a song that maxes out your CPU, & a light song still takes the entire duration plus the time to dither on top of that! Marc Poirier -- [ Destroy FX - http://www.smartelectronix.com/~destroyfx ]

On Monday, April 1, 2002, at 10:33 , Marc Poirier wrote: > First of all, you are confusing dithering with truncating. > Truncation is the process of reducing the bit depth & thereby > throwing away some resolution. Dithering is the process of > compensating for the resolution loss using fancy lowest-bit-twiddling > algorithms. These steps can be performed in either order, but given > what Logic is doing, I would guess that it writes the initial file at > the truncated bit depth & then dithers. I'm not confusing the two. And these steps can't just be performed in any order, at least not with something like POWr, which by the way stands for Psycho-acoustically Optimized Wordlength Reduction, which already in the term implies that these are not two different things here. Yes, you can just truncate. Yes, you can also apply a random noise function to a truncated datafile, to smear the truncation artefacts. No, you cannot apply optimized dithers and noise shaping without going from the full wordlength to the reduced wordlength in one step, or at least without referencing the original data, because just looking at the truncated data you have no way of determining the error that is caused by truncating and that needs to be corrected with the noise shaping, which is a way of distributing an error terms over time such that they cancel out. > Logic might process that > file or it might create a second temporary file, so I wouldn't assume > that a second temporary file is being created without checking first > (easy enough, watch your disk usage). And I definitely wouldn't > assume that Logic renders a file at 24 bits first & then truncates a > second file, that would be really wonky... Whatever Logic does, it needs to keep around the error information, and the only way it can do that is by either writing first a 24-bit file, and dithering it down to 16-bit in a second step, or by writing out a 16-bit truncated file along with a second file that contains the error terms, which for the most part will be like writing out a separate 8-bit file that contains the truncated bits. Still adds up to 24-bit. None of that matters however, since the additional use of disk space is just a minor gripe, which would be made up for by the lower CPU usage, were it not for the other shortcomings that are the direct consequence of the new way of handling this dithering/noise-shaping business. >> b) since it's no longer a plug in, it's no longer possible to quickly >> switch dither during playback, to audition which dither works >> best with a track > > Yeah, I agree, this is what I really don't like about the change. I > definitely don't have the patience to render 3 mixdowns & then > compare them all to see which worked best, so I wind up just using > option #1 each time. It would be WAY preferable to have the option > to compare in realtime. The three options sound rather different, amazingly big difference in fact. The difference between the various POWr settings is as significant as different Eq settings. As a matter of fact, we had to go back and re-Eq a bunch of tracks that I got already Eq-ed and that I was supposed to make a CD replication master from. The sonic signature changed enough by means of the various dithering and noise-shaping choices, that they re-Eq-ed the entire list of songs, precompensating for the expected effect of the dither used. Not being able to stick the dither right into the signal chain, just like Eq, Compressors, and other things that affect the sonic signature of a track is a real bummer. >> What's the advantage of the new method? > > Absolutely nothing so far as I can see. My only guess is that maybe > since Emagic are licensing the algorithm, it was delivered in a > manner that could not be integrated into Logic's realtime internal > processing system. That's all I can guess, because otherwise this is > a totally lame approach. > > You know how people here debate about realtime bounces vs. the option > for offline bounces? Well now we get both, & as a result the worst > of both worlds! Some things get bounced in realtime & then others > things happen offline afterwards. So you still can't bounce a song > that maxes out your CPU, & a light song still takes the entire > duration plus the time to dither on top of that! I thought Logic 4.8.1 already had POWr. Wasn't the POWr dither part of one of the point-upgrades in Logic 4? If so, it wouldn't be an issue with the algorithm. Also, I think in PeakVST POWr is a plug-in, if I remember correctly. I fear that eMagic made this change to make things more foolproof, similar to the fact that in Logic 4.x the dither/noise-shaper plug-in *had* to be the last plug-in in the chain. Good intention, but what if I want to break the rules, because it creates a sound I happen to like, even though it's not what the inventor intended? I should have the freedom. Heck, that's why I feel free to buy my hair brush in the pet section of the supermarket, because there I get a better brush for less money than if I go and buy the thing in the personal care section. ;-) Any chance the old behavior can be brought back, say in 5.2 or 5.1.2? Ronald ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~ "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." G.B. Shaw | rcfa @ cubiculum . com | NeXT-mail welcome