 
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
|
|
Audio Asylum Thread Printer Get a view of an entire thread on one page |
For Sale Ads |
65.184.71.10
In Reply to: If you quote, then please attribute your quote . . . posted by Martin419 on September 5, 2005 at 09:24:09:
The quote came from the developer of the DAW software.Does that help? ;-)
Follow Ups:
Q: "Does that help?"A: Not anybody reading your post, because you still haven't attributed it.
But since you can't be bothered, I shall:
http://www.steinberg.de/Steinberg/NewsDisplay9193.html?NewsID=3722&Langue_ID=2
By the way, no confusion exists at all.
[In reference to: > > First of all, with computer processors, "64-bit" refers to the way computer memory is accessed. It has nothing to do with sound, and computer processors don't use PCM. < <]
1. The Digital Audio workstation is a AMD Opteron 64 bit, Windows XP Pro machine;
2. That DAW uses PCM mixing (in 96kHz/24bit to be specific.)
. . . It was "tracked" in analog:Indeed, Ainlay actually says: " I then dump the initial tracking to Nuendo at 96k and carry on in the digital domain . . . "
Anyway, so much for the SACD of BIA. The truth is that the SACD was converted to DSD from Ainlay's 96kHz PCM files. Therefore the 96kHz DVD-Audio mix is the closest we can get to Ainlay's work for this album (without physically being in the studio with him).
I don't care.You really should leave the format cheerleading to KEKL. He's so much better at it than you are. :-)
I'm so proud of you that you found it after I gave you that big fat clue! ;-)> > By the way, no confusion exists at all. < <
Perhaps not any more, but prior to my post, you were definitely confused. I'll allow that perhaps your post title of "64-bit PCM" was simply poor wording, rather than confusion; however...
You posted that Michael Bishop was wrong - he wasn't. You surmised that because a Digital Audio Workstation was used, there must not have been analog as part of the process. There was.
Better luck next time!
> > Perhaps not any more, but prior to my post, you were definitely confused. < <You can think that if you like.
> > I'll allow that < <
I don't need your permission for anything.
> > perhaps your post title of "64-bit PCM" was simply poor wording, rather than confusion; however... < <
I see, you are changing your mind already. Poor confused man you are.
> > You posted that Michael Bishop was wrong - he wasn't. "
Bishop was wrong.
Bishop said: "the new surround mix was performed in the analog domain".
But the "mix" was not "performed" in the analog domain. Rather, the analog tracks were "dumped" to Nuendo and mixed in 96/24.
(see my other post)
You were wrong.Now you're thrashing about, trying to recover, all because it was me who pointed it out, and you can't stand that. The thrashing doesn't help, it only makes it worse. Quit while you're behind ;-)
Your SACD cheerleading hero Mike Bishop was wrong. You can't stand that. BIA was not "mixed" in analog. It was "mixed" in 96/24 on a 64bit DAW. As per my initial post.
.
.
I don't understand what you guys are arguing about. First of all, Nuendo always defaults to 32 bit internally. Do any of us have proof that he dumped the analog tracks into Nuendo at 96/24 and then actually stepped down to 24 bit internal mixing?Remember that when even *fading* two 16 bit signals of unequal level in a 24 bit environment, your net dynamic range will end up higher than 16 bits.
Similarly when doing an additive mix on two 24 bit signals in a 32 (or yes, 64 bit) internal environment.
Now, okay, he didn't render out to DSD most likely. But I haven't seen quotes as to what his original caputre of the analog tracks were; Yes he 'went on at 96/24 from there' but really, if any of you guys have ever USED Nuendo you KNOW that once the tracks are on the DAW, they are processing at 32 bits. Not memory access. 32 bit PCM internal precision. I have no idea if Nuendo on the A64 can start using doubles efficiently and operate at 64 bits internally.
But the long and short of it is: Yeah, he mixed digital. No, that doesn't mean it sucks. Yes, the a64 can have an effect on the internal precision of the mix's bit depth and in turn the final render when dithered.
I can take 16 analog tracks into Nuendo at 192/24, mix at 192/32 (no you are not 'adding data', you are preserving data the moment you begin to fade, pan or, ... 'mix' - if you remained at 24 bits in this domain you would LOSE data which is why FEW 24 bit DAWs make PCM operations at 24 bits internally!) decimate 96/24 directly to DSD here, right now. I can take DSD and accumulate it to 96/24 as well.
The long and short of it is: we have a better copy of BIA now than we used to, and yes, it does take advantage of the capabilities of both formats. Maybe not in "PURE DSD" and maybe not in the most pristine analog to digital manner some anal Intelligent Chip types would appreciate,
but the output is damned better than Redbook, and that output has landed on both SACD and DVD-A; I've got both, and they're both done very well.
> > I don't understand what you guys are arguing about. < <Martin is arguing. I am merely laughing. ;-)
> > First of all, Nuendo always defaults to 32 bit internally. Do any of us have proof that he dumped the analog tracks into Nuendo at 96/24 and then actually stepped down to 24 bit internal mixing? < <
I've played with Nuendo. Can't claim to be an expert in it, because I don't do that stuff anymore, but I have a little bit experience with it. Nuendo uses 32-bit float, so basically it means you can do 32-bit floating point calculations on 24-bit data. It's not "32-bit audio."
FYI, Nuendo is not capable of accessing the extended memory addressing of the AMD 32/64 processors. Even if it was, it would only buy extra memory address space; it doesn't buy you more than 32 bits of precision on calculations, since the AMD processors are not "true" 64-bit processors like the Alpha, SPARC, PA-RISC, Itanium, or Power.
> > I can take 16 analog tracks into Nuendo at 192/24, mix at 192/32 (no you are not 'adding data', you are preserving data the moment < <
Yeah, sort of. I agree that you are not "adding data." You are utilizing 32-bit floating point precision for calculations. 24-bit mantissa plus 8-bit exponent = 32-bit precision.
> > The long and short of it is: we have a better copy of BIA now than we used to, and yes, it does take advantage of the capabilities of both formats. < <
Since none of us were there at the studio, and there isn't any documentation that I'm aware of that describes EXACTLY how Ainlay does what he does, all is speculation. I'm inclined to believe "SACD Cheerleader" (and friend of Chuck Ainlay) Michael Bishop's statements over Martin's WAGs and desperate cheerleading attempts. :-)
I agree we have a better version. As I said to Martin, I don't care what encoding scheme was used. Only Martin seems to care, and apparently he cares badly enough to be wrong about it. :-)
Michi said:*** I can take 16 analog tracks into Nuendo at 192/24, mix at 192/32 (no you are not 'adding data', you are preserving data the moment ***
Racerguy said:
*** Yeah, sort of. I agree that you are not "adding data." You are utilizing 32-bit floating point precision for calculations. 24-bit mantissa plus 8-bit exponent = 32-bit precision. ***
Actually, you need more than 24 bit fixed point/32-bit floating point just to "preserve data", due to quantization from an accumulation of round off errors.
In fact, arguably, you need up to double the original precision (24 bits x 2 = 48 bits, which will conveniently fit into a 64-bit floating point representation) to avoid numerical inaccuracies. And even then you may still lose accuracy in pathological situations (or if the algorithm was badly coded).
One of the advantages of analog is that you don't have to worry about these things. :-) However, I must say the benefits of digital editing outweighs the pain :-)
Of course, we'll gloss over Martin's previous claim that editing in PCM offers "infinite precision" :-)
You wrote: > > Of course, we'll gloss over Martin's previous claim that editing in PCM offers "infinite precision" < <I never said "infinite precision".
for fun, you should repeat exactly what you originally posted. it's even *more* amusing!anyway, it was only fair after all the deliberate lies you posted about me just because you didn't agree with my posts on DualDiscs. That was seriously disturbing.
I see. So you've evidently decided to abandon logic and resort to tit-for-tat sniping.Now, about these "lies" Christine, if it's about your living/listening room, well firstly I can honestly swear that I thought you told me it was in an "apartment". But this is really irrelevant in the context of the discourse in question (of about a month ago), since you had uploaded pictures of your room on your website (which you have showed to me), which is indeed no bigger than an average room in an apartment. My original point (and adjective used: "modest") being to imply that those four new power amps (circa 2 x 200+ watts RMS each) are somewhat overkill, not only in relation to the "modest" size of your room, but also in relation to the very low level of volume at which you listen. No offence was intended. I'm sorry you took it that way.
And what other "lies" were you referring to?
DualDiscs' CD sides rip just fine on my brother's PC at high speed on his Memorex CD-ROM drive. Using the standard Windows XP included tools. No errors reported.
...someone will write DAW software for a workstation with a processor that can do real justice to floating point operations. It's a shame to see processors with 32 64-bit FP registers used for boring tasks like running Sendmail. ;-)
I'm not sure, but I thought Samplitude/Sequoia used 64-bit fp for some operations, don't know about Cubase/Nuendo.The problem with 64-bit fp is that it's too slow to be really usable. I'm not sure whether Samplitude resamples in 64-bit fp, but in Ultra High 2 mode, Samplitude takes hours to resample 1 hour of music (on a 3GHz processor).
By the way, Cakewalk has announced a 64-bit version of Sonar, but apparently all it means is that they have recompiled the application, and it can take advantage of extended memory addressing. I don't think the numerical accuracy of the processing algorithms have improved (although the Cakewalk press release mentions potential improvement from better utilisation of the 64-bit registers).
> > I thought Samplitude/Sequoia used 64-bit fp for some operations, don't know about Cubase/Nuendo < <Steinberg didn't give up on the Atari ST until just a couple of years ago ;-)
and the MIDI sequencing implementation is *still* better on the Atari than the latest/greatest PC version. Some people are still moaning that there are certains things you can do on the Atari version that you can't on the PC version :-)
"Nuendo uses 32-bit float, so basically it means you can do 32-bit floating point calculations on 24-bit data. It's not "32-bit audio.""That's what I figured. So talk about 64-bit integer math is irrelavant.
"Even if it was, it would only buy extra memory address space; it doesn't buy you more than 32 bits of precision on calculations, since the AMD processors are not "true" 64-bit processors like the Alpha, SPARC, PA-RISC, Itanium, or Power."
Huh? All those CPUs can do 64-bit integer math, and 64-bit floating point. The AMD/Intel chips can also do 80-bit floating point (an IBM PC from 1981 can do 80-bit!)
Perhaps racerguy was referring to instruction set orthogonality.The x86 instruction set is the least orthogonal of commercially available microprocessors, and unfortunately still regains vestiges of it's 16-bit origins. 64-bit addressing, registers and processing are very clearly an afterthought in the instruction set extensions.
The original 8087 numeric coprocessor used in the IBM PC allows the use of 80 bit internal accuracy, and also has support for two proprietary 80-bit floating point representations (a proprietary 80-bit extension to the IEEE format, plus a BCD format with 17 digit accuracy). Neither of these formats were well supported by compilers, and were avoided by developers because the use of non-standard numerical formats can lead to unforeseen numerical instabilities, which then requires additional testing.
All this has nothing to do with the original topic, but it seems to me that the discussion has degenerated into point-scoring on arcane knowledge of microprocessor architecture, so i thought i'll join in! :-)
"Nuendo uses 32-bit float, so basically it means you can do 32-bit floating point calculations on 24-bit data. It's not "32-bit audio.""Actually, it is. In Nuendo, each sample, while it is in the DAW, exists as a 32 bit value by default, not 24.
The operations on several, or accumulated 24 bit samples at 32 bit precision *can indeed* result in 32 bit samples (or higher!) as Christine explained above.
Now I think we all agree that 32 bit PCM was not going into the system, and 32 bit PCM was not going out.
But while in Nuendo, yes, the music could have easily existed as 32 bit pcm. Unless he set everything to 24 bit, which you can do with as simple pulldown. (But on new project start, it is 32 bit.)
> > Huh? All those CPUs can do 64-bit integer math, and 64-bit floating point. The AMD/Intel chips can also do 80-bit floating point (an IBM PC from 1981 can do 80-bit!) < <
The AMD/Intel 32/64 chips can do up to four single-precision floating point operations per CPU cycle. SSE2 can support packed double-precision FLOPs, but the software/OS has to support it.
The IBM PC from 1981 could not do floating point calculations without an add-on math coprocessor (which most did not have). IIRC, the 8087 supported basic single- and double-precision calcs. Again, the software had to be written to take advantage of it.
The "real" 64-bit processors have had native double-precision since their beginning.
"The AMD/Intel 32/64 chips can do up to four single-precision floating point operations per CPU cycle. SSE2 can support packed double-precision FLOPs, but the software/OS has to support it."Irrelevant.
"The "real" 64-bit processors have had native double-precision since their beginning."
Your definition is silly and arbitrary and the CPUs you listed don't even fit it. SPARC, which you listed as "real", like x86 did not originally have an integrated FPU.
I forgot, you just like to argue.Speaking of irrelevant, the first several SPARCs weren't 64-bit. I wasn't talking about those.
Since it's clear that, as usual, you want to get into a totally pointless, completely off-topic argument, I'm done with you in this thread.
Find someone else to spar(c) with.
I'm not arguing, I'm teaching.You previously wrote:
"The "real" 64-bit processors have had native double-precision since their beginning""Speaking of irrelevant, the first several SPARCs weren't 64-bit. I wasn't talking about those."
In that case, we can say that according to YOUR quirky definition, the AMD64 CPUs are "real" 64-bit processors, since they always had native double-precision (and native extended precision - a feature that all the other CPUs you listed save Itanium lack).
Perhaps you would like to revise your original statement that, "...it doesn't buy you more than 32 bits of precision on calculations, since the AMD processors are not "true" 64-bit processors like the Alpha, SPARC, PA-RISC, Itanium, or Power."
Some of your information is correct, but some of it is totally wrong, and I am not going to waste my time or forum space trying to correct you, especially since it will just continue this stupid argument.OK?
These are very simple matters of fact. Either AMD64 processors can do 64-bit arithmetic (integer and float), or they can't. You say they can't. You're wrong. Period.Now, what you decide to call a "real" CPU is your business. I can't say you're wrong about that, I can only point out why it's silly.
This post is made possible by the generous support of people like you and our sponsors:
Top of Page ]
[ Contact Us ]
[ Support/Wish List ]
[ Copyright © 2025, Audio Asylum, all rights reserved ]
