G5 : 64 bits or 32 bits ? - Page 3

[quote]Originally posted by Eric D.V.H:
<strong>
doubt that. try(If you have a large monitor set at a high resolution) popping open Photoshop and do a large, simple gradient. notice the slight striation and dithering?
</strong><hr></blockquote>

Well, this is exactly the kind of thing I was mentioning later on in the paragraph about 8 bits per channel and mainly monochromatic images. If you've only got 256 shades of, say, blue and do a blue gradient across the screen, you'll of course notice the steps.


[quote]<strong>
Really? have you checked out your PowerMac? how about your DVD player? looked into your DV camcorder? I'd be willing to bet that the formermost has a 16-bit audio I/O set-up. while the latter two both bear mere 10-bit audio hardware.
</strong><hr></blockquote>

Hehe, got me wrong there. Of course I was not trying to say that the majority of ADCs and DACs are 24/96 today, but rather that the majority of the ones that technically are, most don't manage to actually come close to the SNR theoretically possible at that bit depth.
(Besides, I don't really think any non-computer DVD-player that costs more than $20 comes with 10 bit DACs...)


[quote]<strong>
Emphasis on the "Current". try hooking an older analog LCD to a good SGI/HP/Compaq/IBM etc. machine. this is why I think digital I/O components(Read: those stupid USB speakers and ADC monitors Apple makes) are a bad idea.
</strong><hr></blockquote>

Well, the "analog" LCDs have their ADCs built-in, and I doubt they put completely "oversized" ones in there upon assembly. So unless you replace them, the situation is no better than with digital LCDs.


[quote]<strong>
Yup. whereas 24-bit only has around sixteen million(16,777,216) colors, 32-bit can theoretically do four billion(4,294,967,296). 48-bit can do up to two hundred and eighty one trillion(281,474,976,710,656). and full 64-bit can do over a whopping three hundred and forty duodecillion(340,282,366,920,938,463,463,374,607,4 31,768,211,000)!
</strong><hr></blockquote>

Um, AFAIK 32bit colors are really only 24bit colors, plus 8 bits alpha channel. The same would probably be true for 64bit (3x16 color + 1x16 alpha).


[quote]<strong>
and the power of high bit depth AD/DA circuitry could be tapped in a less CPU taxing fashion with palettes(Remember how a lot of games could get WAY more than 256 colors on early Macs? they did this by selecting 256 individual colors out of a static 16M color palette).
</strong><hr></blockquote>

I don't think palettized display modes and CLUTs will return any time soon.
While it let's you do nice palette cycling effects and stuff on output, and saves VRAM, it get's really complicated when you go the other way around (capturing video to palettized colors, e.g.).


[quote]<strong>
Using AltiVec that is. can you say "2x integer speed penalty"? like I said before. you need AT LEAST 64 bits throughout ALL of the CPU for maximum speed.
</strong><hr></blockquote>

What penalty are you talking about?

Also, how useful is it to perform integer ops on 64 bit numbers as long as you don't have 64 bits per color channel? I mean, how often do you really want to add two (RGBA) pixels with carries across color channels, or multiply (RGBA) by (RGBA)?


[quote]<strong>
That's what they said about 16-bit CDs. compare a 32-bit signal to an analog(A good one) signal on an oscilloscope. you'll notice tiny plateau-like steps in the digital signal. 32-bit is good. but 48-bit. or better yet. 64-bit audio is quite a bit better.
</strong><hr></blockquote>

More resolution of course always leads to a more realistic digitized representation, but there's a point of diminishing returns, and beyond that, it's just not worth the effort. What good is 64bit audio if you can only tell the difference to 32bit with some audio equivalent of a raster electron microsocope?

Bye,
RazzFazz

[ 04-09-2002: Message edited by: RazzFazz ]</p>

AirSluf:

I'm glad you've found the smilies. Add enough smilies and other childish and ridiculous stuff to your post and distract from what it is all about and you'll win, even though your arguments (funnels) were proved wrong a long time ago (in theory).

(((Oh, and by the way: I've set up a few posix threads and concurrently read a directory containing 5000 files (each file's name, size and modification date, name alone wouldn't require individual inode reading in UFS). No thread locking occures on my SP Mac (both HFS+ and UFS) (which is of course what everybody except you was expecting), so I think even you should realize by now, that funnels aren't responsible for the finder blocking, as we have now an empirical proof too.)))

As for the 64 bit bus discussion and my posts ("...they would be accepted at face value"): Programmer has never been talking about byte reading but rather about bus traffic increase in general. I think his point indeed is valid, but so is mine. The problem is that we were quoting and arguing each other's posts several times although we were talking about very different things. So what's the point of continuing the discussion if we basically agree but discuss for the discussion's sake? Well, that's my take of it.

Now if you want to say something, read my first post in this thread where I was talking about Amorph's statement and tell me what's wrong about it. Alternatively, just post some smilies (may be worth more than 1000 words in your case).

[ 04-09-2002: Message edited by: 123 ]</p>

Everyone count to ten and take a deep breath.

This is an informative thread. Let's keep it that way.

[quote]Originally posted by 123:
<strong>As for the 64 bit bus discussion and my posts ("...they would be accepted at face value"): Programmer has never been talking about byte reading but rather about bus traffic increase in general. I think his point indeed is valid, but so is mine. The problem is that we were quoting and arguing each other's posts several times although we were talking about very different things. So what's the point of continuing the discussion if we basically agree but discuss for the discussion's sake? Well, that's my take of it.
</strong><hr></blockquote>

Exactly. Multiple discussions in the same thread got mixed up. Apologies for any confusion.

Quick question about memory controllers on CPUs:

Someone said (to lazy to check) that if Moto build a memory controller into the G5 it had better be really forward-looking. Sounds fair enough, but couldn't this part be flash-programmable? I thought that Nvidia do this kind of thing already, though I don't know the specifics.

Flash programmable would end up being far to slow for the kind of bandwidth the G5 needs. You can't expect the G5 to last forever as a high end CPU, so i would suggest a memory technology that is suited at the time. DDR333 should be fine for the life of the G5. Is the DDR-II spec finished though?

[quote]Originally posted by Outsider:
<strong>Flash programmable would end up being far to slow for the kind of bandwidth the G5 needs. You can't expect the G5 to last forever as a high end CPU, so i would suggest a memory technology that is suited at the time. DDR333 should be fine for the life of the G5. Is the DDR-II spec finished though?</strong><hr></blockquote>

Considering the amount of time between the G4 and G5, I should hope that they either immediately support better than DDR333 or their memory controller design is flexible and can be easily enhanced in future revisions. Better yet, if it is a modular chip and Apple provides that module -- Motorola's current showing in the chipset department is rather lame!

[quote]Originally posted by powerdoc:
<strong>What you say is true in the absolute, but there is no need of a 24 bit audio if the analogic conversion , amplification , and the HP are lame.
I doubt that we can see a difference when we ear a 16 bit audio signal compared to even a 64 bit signal on a basic HP (like the lame built-in HP of the tower). The problem is not coming from an huge prize difference between a 24 bits audio chipset and a 16 bit one, but from the huge difference of prize, between a standart qualities of amplifications and HP, and a very good one.

This is the mean reason why in the domain of HI-FI there is so huge difference of prizes. If you don't believe me just go in an auditorium and just try some different stuffs (if you are an audio pro, i don't need to convice you on that particular subject)</strong><hr></blockquote>

That could easily be solved by a little EM/RF insulation. as seen on <a href="http://www.orcawerks.com/sgi/o2/page3.html" target="_blank">higher</a> end pieces of audio equipment.

Eric,

[ 04-10-2002: Message edited by: Eric D.V.H ]

[ 04-10-2002: Message edited by: Eric D.V.H ]</p>

[quote]Originally posted by RazzFazz:
<strong>Well, this is exactly the kind of thing I was mentioning later on in the paragraph about 8 bits per channel and mainly monochromatic images. If you've only got 256 shades of, say, blue and do a blue gradient across the screen, you'll of course notice the steps.</strong><hr></blockquote>

Precisely. and the only way to solve it is to bump up the bit depth.

[quote]Originally posted by RazzFazz:
<strong>Hehe, got me wrong there. Of course I was not trying to say that the majority of ADCs and DACs are 24/96 today, but rather that the majority of the ones that technically are, most don't manage to actually come close to the SNR theoretically possible at that bit depth.</strong><hr></blockquote>

That could easily be solved by a little EM/RF insulation. as seen on <a href="http://www.orcawerks.com/sgi/o2/page3.html" target="_blank">higher</a> end pieces of audio equipment[/url].

[quote]Originally posted by RazzFazz:
<strong>(Besides, I don't really think any non-computer DVD-player that costs more than $20 comes with 10 bit DACs...)</strong><hr></blockquote>

I do. even many high-end <a href="http://www.panasonic.com/PBDS/subcat/Products/cams_ccorders/f_aj-d410a.html" target="_blank">DV</a> and <a href="http://www.sel.sony.com/SEL/consumer/ss5/home/dvd/dvdplayers/dvp-s9000es_specs.shtml" target="_blank">DVD</a> products have only 10-bit A/D(Ok. I was off by two bits. the DVD player has a 12-bit DAC ). barf.

[quote]Originally posted by RazzFazz:
<strong>Well, the "analog" LCDs have their ADCs built-in, and I doubt they put completely "oversized" ones in there upon assembly. So unless you replace them, the situation is no better than with digital LCDs.</strong><hr></blockquote>

Hmmm you might actually be right on that count. but the LCD's shutters and backlights are fully analog. so you would at most only need to replace the controller subsystems.

[quote]Originally posted by RazzFazz:
<strong>Um, AFAIK 32bit colors are really only 24bit colors, plus 8 bits alpha channel. The same would probably be true for 64bit (3x16 color + 1x16 alpha).</strong><hr></blockquote>

You've just touched on one of my pet peeves. with many programs including multiple alpha channels(Photoshop), specialized maps like Z, bump and glow(Games and 3D modelers) as well as multiple internal color channels(Weather, solid and fluid physics apps). combined with the fact of that NONE of this ever leaves the computer. chopping off bits from each byte purely for the storage of just _one_ extra channel of data is stupid. I honestly can't think of one good reason to do this.

[quote]Originally posted by RazzFazz:
<strong>I don't think palettized display modes and CLUTs will return any time soon.
While it let's you do nice palette cycling effects and stuff on output, and saves VRAM, it get's really complicated when you go the other way around (capturing video to palettized colors, e.g.).</strong><hr></blockquote>

But think of the GAMMEZZZ .

[quote]Originally posted by RazzFazz:
<strong>What penalty are you talking about?</strong><hr></blockquote>

The one where you try to squeeze a 64-bit byte through a 32-bit processing unit. and have to do it in two clock cycles instead of one as a result.

[quote]Originally posted by RazzFazz:
<strong>Also, how useful is it to perform integer ops on 64 bit numbers as long as you don't have 64 bits per color channel? I mean, how often do you really want to add two (RGBA) pixels with carries across color channels, or multiply (RGBA) by (RGBA)?</strong><hr></blockquote>

It's useful. FPUs and VPUs are hot stuff. but the humble IPU still has it's place.

[quote]Originally posted by RazzFazz:
<strong>More resolution of course always leads to a more realistic digitized representation, but there's a point of diminishing returns, and beyond that, it's just not worth the effort. What good is 64bit audio if you can only tell the difference to 32bit with some audio equivalent of a raster electron microsocope?</strong><hr></blockquote>

Well _I_ can hear it :cool: . and besides. this would allow you to do MUCH more processing on a piece of audio before the resulting degradation became noticable on the final result(Kind of like the reason audio professionals today use 24/96 and 32/192 mixing on a product that they _know_ will be downsampled to 16/48 for CDs).


Eric,

[ 04-10-2002: Message edited by: Eric D.V.H ]</p>

[quote]<strong>
You've just touched on one of my pet peeves. with many programs including multiple alpha channels(Photoshop), specialized maps like Z, bump and glow(Games and 3D modelers) as well as multiple internal color channels(Weather, solid and fluid physics apps). combined with the fact of that NONE of this ever leaves the computer. chopping off bits from each byte purely for the storage of just _one_ extra channel of data is stupid. I honestly can't think of one good reason to do this.
</strong><hr></blockquote>

The alpha channel in the frame buffer is often used for the stencil or alpha buffer. As graphics effects get more complex the use of the destination alpha gets heavier and heavier. Storing it as part of the primary frame buffer saves quite a bit of bandwidth.

[quote]Originally posted by Programmer:
<strong>The alpha channel in the frame buffer is often used for the stencil or alpha buffer. As graphics effects get more complex the use of the destination alpha gets heavier and heavier. Storing it as part of the primary frame buffer saves quite a bit of bandwidth.</strong><hr></blockquote>

But not enough to justify slicing off 1/4 each byte. what I was saying is that. while single alternate maps/channels are still used in a few things. like OS X's Aqua. the vast majority of alternate map/channel using applications tend to employ _MULTIPLE_ alternate maps/channels.

With all these Z-maps, bump maps, multiple alpha and color channels, luminosity maps, reflection maps....... on and on to infinity. floating around. having one more alternate map/channel hooked on seperately instead of taking up valuable byte word space wouldn't make _that much_ of a difference. and it would certainly make everything look/sound a LOT nicer.

Eric,

[ 04-10-2002: Message edited by: Eric D.V.H ]</p>

[quote]Originally posted by Eric D.V.H:
<strong>But not enough to justify slicing off 1/4 each byte. what I was saying is that. while single alternate maps/channels are still used in a few things. like OS X's Aqua. the vast majority of alternate map/channel using applications tend to employ _MULTIPLE_ alternate maps/channels.

With all these Z-maps, bump maps, multiple alpha and color channels, luminosity maps, reflection maps....... on and on to infinity. floating around. having one more alternate map/channel hooked on seperately instead of taking up valuable byte word space wouldn't make _that much_ of a difference. and it would certainly make everything look/sound a LOT nicer.</strong><hr></blockquote>

In 3D graphics bandwidth is very precious. A lot of effects just need one extra channel, and thus can play in a 32-bit frame buffer with no performance hit. Going beyond that the additional channels are either packed together, in which case you get 4 at the same cost as one... or they are seperate and you have to rely on locality of reference to be efficient. In the packed case we'd normally pile on the effects to use all 4 extra channels, i the seperate case we'd want to minimize them and thus the one freebie is valuable.

This is short term, however. Over the next few years performance and memory will increase enough that I agree with you that the bit depth of the frame buffer (and textures) will increase. 11/11/10 is an obvious first step, but it'll probably grow to a full 16-bits/channel. There may even be cases where a full 32-bit float per channel is desirable.

[quote]Originally posted by Programmer:
<strong>In 3D graphics bandwidth is very precious. A lot of effects just need one extra channel, and thus can play in a 32-bit frame buffer with no performance hit. Going beyond that the additional channels are either packed together, in which case you get 4 at the same cost as one... or they are seperate and you have to rely on locality of reference to be efficient. In the packed case we'd normally pile on the effects to use all 4 extra channels, i the seperate case we'd want to minimize them and thus the one freebie is valuable.</strong><hr></blockquote>

I still think this sort of thing was _never_ really justified. and using 3D accelerators as an example is a bad idea. as 3D games(The main users of such things) tend to be amongst the most alternate map/channel hungry applications out there. and we got along fine on full 8 and 16 bit bytes for years. only switching to the icky 1/4 byte word with 32-bit(24-bit video). if a IIci and a Quadra 660av got along without 1/4 byte words. I think a quad 1.5Ghz PPC 8xx0 could too.

[quote]Originally posted by Programmer:
<strong>This is short term, however. Over the next few years performance and memory will increase enough that I agree with you that the bit depth of the frame buffer (and textures) will increase.</strong><hr></blockquote>

Right on.

[quote]Originally posted by Programmer:
<strong>11/11/10 is an obvious first step, but it'll probably grow to a full 16-bits/channel. There may even be cases where a full 32-bit float per channel is desirable.</strong><hr></blockquote>

Hmmm... after a few calculations. I don't think it works this way. cause see:

• One third of 24-bit=256 different numbers.
• Three thirds of 24-bit stacked atop each other=1024 different numbers.
• Full 24-bit=16,777,216 different numbers.

That means that if they really did split up the byte of each pixel into phosphors. then trucolor would only consist of 1024 colors! I guess they just use the 24-bit number value of a pixel's byte to look up a color out of a single large palette. in which each individual color and shade of gray is assigned a catologue-like binary number.

Eric,

[ 04-10-2002: Message edited by: Eric D.V.H ]</p>

[quote]Originally posted by Eric D.V.H:
<strong>

Hmmm... after a few calculations. I don't think it works this way. cause see:

• One third of 24-bit=256 different numbers.
• Three thirds of 24-bit stacked atop each other=1024 different numbers.
• Full 24-bit=16,777,216 different numbers.

That means that if they really did split up the byte of each pixel into phosphors. then trucolor would only consist of 1024 colors! I guess they just use the 24-bit number value of a pixel's byte to look up a color out of a single large palette. in which each individual color and shade of gray is assigned a catologue-like binary number.</strong><hr></blockquote>

I really don't follow your logic here. Current 24-bit frame buffers (irrespective of the presense of the 8-bit alpha) send the 3 8-bit RGB values to 3 seperate 8-bit DACs. In the future the frame buffer channels will grow -- 11/11/10 is the largest that can fit in 32-bits and will probably be supported by 10-bit DACs. Beyond that 16-bit channels (48-bit pixels) are the next obvious step, but the DACs may still only be 10 or 12 bits except, perhaps, at the high end of the market.

Floating point channels may eventually be possible, but they are mainly a convenience, eliminating the need to convert to/from floating point and the resulting loss in precision (most new graphics engines operate in floating point internally, converting to integer only when writing to memory). If frame buffers are stored in this format, it'll probably only be for intermediate buffers -- the output buffer will likely remain integers.

Regarding the use of 32-bit vs 24-bit: The original reason this was done was for memory alignment issues. Processors fetch and store word aligned values more efficiently, and 24-bit values aren't word aligned. Padding it out to 32-bits allowed pixels to be addressed and manipulated more quickly and easily (consider that computing the byte address of a 24-bit pixel requires a multiply by 3, whereas computing the address of a 32-bit pixel can be done with a shift-by-two). This remains true for 3D accelerators, which now have the capability to actually use the extra 8-bits for something useful. Back in the days of the Quadra when memory was expensive, Apple actually didn't physically provide the extra 8-bit but their pixels were still 32-bits from an addressing point of view -- you just always got a zero alpha on every read.

[quote]Originally posted by Eric D.V.H:
<strong>
That could easily be solved by a little EM/RF insulation. as seen on higher end pieces of audio equipment</strong><hr></blockquote>

I don't see any tech specs on the page linked to...


[quote]<strong>
I do. even many high-end DV and DVD products have only 10-bit A/D(Ok. I was off by two bits. the DVD player has a 12-bit DAC ). barf.
</strong><hr></blockquote>

Oh, I thought you were referring to the audio DAC (which is 24/96 on that DVD deck).

EDIT: Re-reading your original post, you were in fact referring to the audio DAC, and you were mistaken at least in this particular case.


[quote]<strong>
You've just touched on one of my pet peeves. with many programs including multiple alpha channels(Photoshop), specialized maps like Z, bump and glow(Games and 3D modelers) as well as multiple internal color channels(Weather, solid and fluid physics apps). combined with the fact of that NONE of this ever leaves the computer. chopping off bits from each byte purely for the storage of just _one_ extra channel of data is stupid. I honestly can't think of one good reason to do this.
</strong><hr></blockquote>

In fact, this works the other way round. It's not like they had 32bit for the color channels initially, and then thought "oh, damn, need to stick an alpha channel in there too, let's just trim the colors", but rather 24bit colors were the starting point. Now, unfortunately, handling 32bit data chunks is much easier and faster than handling 24bit ones (or any none-power-of-two ones for that matter), so graphics cards stored the 24 bits of color information in one doubleword (32bit) each. So when they had to add alpha information to textures with the advent of 3D acceleration, they just used the remaining, formerly unused 8 bits. But this really only applies to graphics data as stored in VRAM and rather simple formats. It does especially not apply to complex multilayered formats like PSD (which uses 32bit FP per color channel, IIRC).


[quote]<strong>
The one where you try to squeeze a 64-bit byte through a 32-bit processing unit. and have to do it in two clock cycles instead of one as a result.
</strong><hr></blockquote>

My point was that this doesn't apply at all here.
A 32bit color value is not really a continuous 32bit value, but rather 3 (4 with alpha) 8-bit-values grouped together. The same for your 64bit colors: Ech 64bit pixel is made up from 3 16bit color values, and possibly one 16bit alpha value. Because the individual channels are not inter-related, AltiVec can process two such pixels (4 for 32bits) in one operation.


[quote]<strong>
It's useful. FPUs and VPUs are hot stuff. but the humble IPU still has it's place.
</strong><hr></blockquote>

It of course does, but that place is not as related to 64bit colors as you seem to think.


[quote]<strong>
Well _I_ can hear it.
</strong><hr></blockquote>

With all due respect, but I'm 100% positive you could not tell 64bit FP audio from 32bit one with your bare ears.


[quote]<strong>
and besides. this would allow you to do MUCH more processing on a piece of audio before the resulting degradation became noticable on the final result(Kind of like the reason audio professionals today use 24/96 and 32/192 mixing on a product that they _know_ will be downsampled to 16/48 for CDs).
</strong><hr></blockquote>

This is technically true, and as you say it makes quite a lot of sense to use 24/96 when you downsample to 16/48, but you have to keep in mind that the effect is exponential. 48bits of headroom when producing a 16bit CD are nothing short of insane.

Bye,
RazzFazz

[ 04-11-2002: Message edited by: RazzFazz ]</p>

[quote]Originally posted by Programmer:
<strong>I really don't follow your logic here. Current 24-bit frame buffers (irrespective of the presense of the 8-bit alpha) send the 3 8-bit RGB values to 3 seperate 8-bit DACs. In the future the frame buffer channels will grow -- 11/11/10 is the largest that can fit in 32-bits and will probably be supported by 10-bit DACs. Beyond that 16-bit channels (48-bit pixels) are the next obvious step, but the DACs may still only be 10 or 12 bits except, perhaps, at the high end of the market.</strong><hr></blockquote>

Ah. I can see what you were trying to say. but I was noting that it's fundamentally flawed.

If only 8-bits(Binary digits) were being used to tell each phosphor(Or whatever you call it on LCD and plasma displays ) what to do. the laws of base two mathematics would kick in. and each phosphor on the monitor would only be capable of 256 different levels of brightness. as individual colors as a whole are made up of combinations of these things. such a system would have limited the palette range of the computer to a dramatically smaller number than sixteen million. this clearly illustrates my point that colors are defined as a single large binary number. instead of a stack of three smaller ones.

[quote]Originally posted by Programmer:
<strong>Floating point channels may eventually be possible, but they are mainly a convenience, eliminating the need to convert to/from floating point and the resulting loss in precision (most new graphics engines operate in floating point internally, converting to integer only when writing to memory). If frame buffers are stored in this format, it'll probably only be for intermediate buffers -- the output buffer will likely remain integers.</strong><hr></blockquote>

:confused:

[quote]Originally posted by Programmer:
<strong>Regarding the use of 32-bit vs 24-bit: The original reason this was done was for memory alignment issues. Processors fetch and store word aligned values more efficiently, and 24-bit values aren't word aligned. Padding it out to 32-bits allowed pixels to be addressed and manipulated more quickly and easily (consider that computing the byte address of a 24-bit pixel requires a multiply by 3, whereas computing the address of a 32-bit pixel can be done with a shift-by-two). This remains true for 3D accelerators, which now have the capability to actually use the extra 8-bits for something useful. Back in the days of the Quadra when memory was expensive, Apple actually didn't physically provide the extra 8-bit but their pixels were still 32-bits from an addressing point of view -- you just always got a zero alpha on every read.</strong><hr></blockquote>

Same goes for 16-bit. which was also done in full. and like I was saying. the alpha(And everything else other than actual colors) should be hooked on in a later transmission. as there are nearly always yet even more alternate channels/maps tagging along too nowadays. and full 32-bit audio support in current Macs(Aside from the old ASIO implementation. it's even supported in OS 10.1's Core Audio ) further validates my point.

Eric,

[quote]Originally posted by Eric D.V.H:
<strong>
Ah. I can see what you were trying to say. but I was noting that it's fundamentally flawed.
</strong><hr></blockquote>

Actually, it's not flawed, it reality.


[quote]<strong>
If only 8-bits(Binary digits) were being used to tell each phosphor(Or whatever you call it on LCD and plasma displays ) what to do. the laws of base two mathematics would kick in. and each phosphor on the monitor would only be capable of 256 different levels of brightness. as individual colors as a whole are made up of combinations of these things. such a system would have limited the palette range of the computer to a dramatically smaller number than sixteen million. this clearly illustrates my point that colors are defined as a single large binary number. instead of a stack of three smaller ones.
</strong><hr></blockquote>

Absolutely not.
Each pixel on screen is made out of 3 sub-pixels (i.e. three phosphors), each one of which emits color at a different wavelength (red, green and blue, thus "RGB") when hit by the ion beam.
Thus, each pixel can be any combination of the 256 levels of color per sub-pixel. This makes for 256(R)*256(G)*256(B) colors, which (surprise, surprise) equals 16777216 or 2^24 possible colors.

Bye,
RazzFazz

[quote]Originally posted by RazzFazz:
<strong>I don't see any tech specs on the page linked to...</strong><hr></blockquote>

I wasn't looking for tech specs. just a picture of a heavily suited-up sound board to show what I meant by "EM/RF insulation".

[quote]Originally posted by RazzFazz:
<strong>Oh, I thought you were referring to the audio DAC (which is 24/96 on that DVD deck).

EDIT: Re-reading your original post, you were in fact referring to the audio DAC, and you were mistaken at least in this particular case.</strong><hr></blockquote>

Oops. we can't all all be perfect can we .

[quote]Originally posted by RazzFazz:
<strong>In fact, this works the other way round. It's not like they had 32bit for the color channels initially, and then thought "oh, damn, need to stick an alpha channel in there too, let's just trim the colors", but rather 24bit colors were the starting point. Now, unfortunately, handling 32bit data chunks is much easier and faster than handling 24bit ones (or any none-power-of-two ones for that matter), so graphics cards stored the 24 bits of color information in one doubleword (32bit) each. So when they had to add alpha information to textures with the advent of 3D acceleration, they just used the remaining, formerly unused 8 bits. But this really only applies to graphics data as stored in VRAM and rather simple formats. It does especially not apply to complex multilayered formats like PSD (which uses 32bit FP per color channel, IIRC).</strong><hr></blockquote>

No they didn't! they started off with 1-bit(Monochrome), 2-bit(4 colors), 4-bit(16 colors), 8-bit(256 colors) and (later)16-bit(Thousands of colors). _all of which_ divided evenly by 32(And by 16 too. the bit depth of <a href="http://www.everymac.com/systems/apple/mac_classic/stats/mac_128k.html" target="_blank">The Original Macintosh's data path</a>). I have no idea of why they decided to reserve the last quarter of the byte for alternate channels/maps. probably to go along with the money grubbing synthesizer/digitizer manufacturers.

[quote]Originally posted by RazzFazz:
<strong>My point was that this doesn't apply at all here.
A 32bit color value is not really a continuous 32bit value, but rather 3 (4 with alpha) 8-bit-values grouped together. The same for your 64bit colors: Ech 64bit pixel is made up from 3 16bit color values, and possibly one 16bit alpha value. Because the individual channels are not inter-related, AltiVec can process two such pixels (4 for 32bits) in one operation.</strong><hr></blockquote>

Refer to prior comments to Programmer regarding the likelihood of a pixel's byte being quartered and drawn.

[quote]Originally posted by RazzFazz:
<strong>With all due respect, but I'm 100% positive you could not tell 64bit FP audio from 32bit one with your bare ears.</strong><hr></blockquote>

Pull out a good, analog laserdisc, hook up the player and your computer to your headphones through a good audio switcher and try it yourself(and make sure the analog stuff is top notch. bad analog sounds MUCH worse than bad digital. but good analog sounds quite a bit better than any digital audio does, has or ever will).

[quote]Originally posted by RazzFazz:
<strong>This is technically true, and as you say it makes quite a lot of sense to use 24/96 when you downsample to 16/48, but you have to keep in mind that the effect is exponential. 48bits of headroom when producing a 16bit CD are nothing short of insane.</strong><hr></blockquote>

Don't forget the future. 24/192/8.2 DVD-Audio discs are the end-format of the future. and it never hurts to be prepared .


Eric.

[ 04-12-2002: Message edited by: Eric D.V.H ]

[ 04-12-2002: Message edited by: Eric D.V.H ]</p>

[quote]Originally posted by RazzFazz:
<strong>Actually, it's not flawed, it reality.</strong><hr></blockquote>

We'll see

[quote]Originally posted by RazzFazz:
<strong>Absolutely not.
Each pixel on screen is made out of 3 sub-pixels (i.e. three phosphors), each one of which emits color at a different wavelength (red, green and blue, thus "RGB") when hit by the ion beam.
Thus, each pixel can be any combination of the 256 levels of color per sub-pixel. This makes for 256(R)*256(G)*256(B) colors, which (surprise, surprise) equals 16777216 or 2^24 possible colors.</strong><hr></blockquote>

Hmm... your math is correct. but you're forgetting something. Macs originally used whole word sizes indivisable by three. such as eight and sixteen. to represent color. suddenly switching to a quartered byte to represent color would have proven practically impossible. as well as crippling either the new colors or the old ones.

Eric,

[quote]Originally posted by Eric D.V.H:
<strong>
No they didn't! they started off with 1-bit(Monochrome), 2-bit(4 colors), 4-bit(16 colors), 8-bit(256 colors) and (later)16-bit(Thousands of colors).
</strong><hr></blockquote>

Argh, of course. I meant that people originally used 24 bit wide "true colors".
(Besides, you forgot the early "high color" video cards which had 15-bit-colors (5 bits per channel). Also, each palette entry in the Amiga was a 12-bit-color.)


[quote]<strong>I have no of why they decided to reserve the last quarter of the byte for alternate channels/maps. probably to go along with the money grubbing synthesizer/digitizer manufacturers.
</strong><hr></blockquote>

No. They used 32 bits to store 24bit color values for alignment reasons. Cf. Programmer's comment above.


[quote]<strong>
Refer to prior comments to Programmer regarding the likelihood of a pixel's byte being quartered and drawn.
</strong><hr></blockquote>

???


[quote]<strong>
Pull out a good, analog laserdisc, hook up the player and your computer to your headphones through a good audio switcher and try it yourself(and make sure the analog stuff is top notch. bad analog sounds MUCH worse than bad digital. but good analog sounds quite a bit better than any digital audio does, has or ever will).
</strong><hr></blockquote>

Either you accidentally called a vinyl record a laserdisc, or you just didn't make a lot of sense. Laserdiscs are digital.


[quote]<strong>
Don't forget the future. 24/192/8.2 DVD-Audio discs are the end-format of the future. and it never hurts to be prepared .
</strong><hr></blockquote>

That's still 40 bits headroom, which is still completely unrealistic.
Have you ever seen anybody use more than 100% headroom?

And again, while the tech stuff get's better all the time, our ears don't.

Bye,
RazzFazz

[quote]Originally posted by Eric D.V.H:
<strong>
Hmm... your math is correct. but you're forgetting something. Macs originally used whole word sizes indivisable by three. such as eight and sixteen. to represent color. suddenly switching to a quartered byte to represent color would have proven practically impossible.</strong><hr></blockquote>

a) How exactly do 1- and 4-bit-colors fall into the "whole word sizes" category?

b) 8-bit-colors were palettized, and as such a wholly different beast (palettized colors of course can indeed not be subdivided in any sensible way).

c) 16-bit-colors use 5 bits each for red and blue, and 6 bits for green (IIRC), because our eyes are more sensitive to the latter than to the former two.


[quote]<strong>
as well as crippling either the new colors or the old ones.
</strong><hr></blockquote>

Whatever that's supposed to mean...

Bye,
RazzFazz

[quote]Originally posted by RazzFazz:
<strong>a) How exactly do 1- and 4-bit-colors fall into the "whole word sizes" category?</strong><hr></blockquote>

Simple.

• 32÷32=1
• 32÷8=4

[quote]Originally posted by RazzFazz:
<strong>b) 8-bit-colors were palettized, and as such a wholly different beast (palettized colors of course can indeed not be subdivided in any sensible way).</strong><hr></blockquote>

Palettized colors are stored the same way inside the file as non-palettized colors. the only difference is that the _whole screen_ is changed to the custom palette as specified prior to(That is. separately from when) the colors themselves are read. that's why the colors that weren't designed with that palette in mind(Like your desktop. while playing a windowed game) looked all phreaky.

[quote]Originally posted by RazzFazz:
<strong>c) 16-bit-colors use 5 bits each for red and blue, and 6 bits for green (IIRC), because our eyes are more sensitive to the latter than to the former two.</strong><hr></blockquote>

<img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" /> :confused: <img src="graemlins/bugeye.gif" border="0" alt="[Skeptical]" />
That sounds a little too fishy even for AppleInsider. I'd like a little substantiation on that one before I'll swollow it.

Eric,

[ 04-12-2002: Message edited by: Eric D.V.H ]</p>

Eric, regarding pixel formats and RGB555, RGB565 and RGB888, you might want to take a look at this stuff:

<a href="http://grafi.ii.pw.edu.pl/gbm/matrox/ramdac.html" target="_blank">http://grafi.ii.pw.edu.pl/gbm/matrox/ramdac.html</a>
<a href="http://www.americanpredator.com/downloads/information/Video815E.pdf" target="_blank">http://www.americanpredator.com/downloads/information/Video815E.pdf</a>
<a href="http://www.law.emory.edu/fedcircuit/aug2001/00-1257.wp.html" target="_blank">http://www.law.emory.edu/fedcircuit/aug2001/00-1257.wp.html</a>

(Look for "direct color".)

HTH,
RazzFazz

[quote]Originally posted by Eric D.V.H:
<strong>
Simple.

32÷32=1
32÷8=4
</strong><hr></blockquote>

Are you pulling my leg or something?
You can't be serious here, can you?
Now one bit is supposed to be "whole byte size" because 8 divided by 8 is 1?


[quote]<strong>
Palettized colors are stored the same way ones inside the file as non-palettized ones.
</strong><hr></blockquote>

What do you mean?
Of course they are just bytes (we're talking about DACs and VRAM here, not files, BTW, even though the situation is the same there), but that's of course true for anything stored anywhere inside your computer. The difference is that they are interpreted in different ways, depending on whether they are direct or indexed colors.


[quote]<strong>
the only difference is that the _whole screen_ is changed to the custom palette as specified before(That is. separately from when) the colors themselves are read.
</strong><hr></blockquote>

The difference between palettized colors and direct colors is that the former ones are translated using the color lookup table, and the corresponding values from the CLUT are then passed on to the RAMDACs. Direct colors, on the other hand, are passed straight to the DACs.
For example, in 8-bit-mode, each pixel can be any one of 256 possible colors stored in the CLUT. Each one of the 256b CLUT entries contains three bytes, one each for red, green and blue.
So color no. 1 might translate to (0,0,255), meaning bright blue, whereas color 15 might translate to (255,0,255), meaning violet. That way, your palette contains 256 colors out of 16.7mio., but you can only ever have at most 256 of them on your screen simultaneously.


[quote]<strong>that's why the colors that weren't designed with that palette in mind(Like your desktop. while playing a windowed game) looked all phreaky.
</strong><hr></blockquote>

No, that happens because your flipper overwrites CLUT entries with his own values, and suddenly the pixel colors translate to different ones than before (i.e. color no. 1 might now have become (63, 63, 63) or dark grey). Since the still "thinks" color no. 1 is bright blue, all bright blue areas on the screen surrounding the game turn into dark grey.

Read the links I mentioned above, I hope they'll clear some things up.


[quote]<strong> <img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" /> :confused: <img src="graemlins/bugeye.gif" border="0" alt="[Skeptical]" />
That sounds a little too fishy even for AppleInsider. I'd like a little substantiation on that one before I'll swollow it.
</strong><hr></blockquote>

What part of it do you fail to understand?

Imagine a 16 bit color value in VRAM:
xxxxxxxxyyyyyyyy
--1 byte--1 byte

If the graphics card wants to put this on screen, it interprets it in the following way:

rrrrrggggggbbbbb
--red-green-blue

Example:
Let's assume a value of 52647 at some given address in VRAM. In binary representation, this is:

1100110110100111

Now, when the graphics card reads that value, it takes the first 5 bits and sends them to the red DAC, then sneds the next 6 bits to thw green DAC, and finally the remaining bits to the blue DAC:

Red: 11001 = 25
Green: 101101 = 45
Blue: 00111 = 7


In a hypothetical 16 bit indexed color mode, the graphics card would look up the 52647th entry in the color lookup table, and then load the individual DACs with the values stored there.

Got it?

Bye,
RazzFazz

[ 04-12-2002: Message edited by: RazzFazz ]</p>

OK. I don't know about all the programming stuff going on here, but Eric is correct about the audio stuff.

CDs are recorded at 16bit/44.1kHz (not 48kHz), and this was specified as a minimal standard. 44.1kHz is just about double the frequency that we can hear at (up to 20kHz). In theory, you can get back the original analog signal, but it requires a lot processing power, and is never observed in reality. Newer audio "standards" (in quotes because they haven't really caught on) such as SACD and DVD-Audio go up to 24bit/192kHz.

Why bother? Because the difference is audible. Probably not on a $40 boom box, but with good headphones or a high-end stereo you can hear the difference. The SACDs just sound more "natural" more like an good quality vinyl LP than do standard CDs.

[quote]Originally posted by Eric D.V.H:
<strong>
<img src="graemlins/hmmm.gif" border="0" alt="[Hmmm]" /> :confused: <img src="graemlins/bugeye.gif" border="0" alt="[Skeptical]" />
That sounds a little too fishy even for AppleInsider. I'd like a little substantiation on that one before I'll swollow it.
</strong><hr></blockquote>

Eric, I'm sorry but you clearly don't know much about computer graphics hardware. I've been doing this stuff for ~18 years now (gawd, has it been that long?!!).

1-bit allowed a 32-bit CPU to manipulate 32 pixels per word.
4-bit was palettized (16 entries) and the actual colour values were stored in the palette as 32-bit words (actually on the Mac it was 3 16-bit values, IIRC).
8-bit was palettized (256 entries) and the actual colour values were stored in the palette in the same form as for 4-bit.
16-bit on the Mac was always 1-bit unused, and 5 bits each of red, green, and blue. On the PC they commonly used 5 bits of red and blue and 6 bits of green.
32-bit for the first few years was just 8-bits each of red, green, and blue but aligned to 32-bits for performance reasons. Some PC cards stored the 8-bit channels seperately, and some stored only 24-bits but this was very inefficient to draw to. Some early Mac video cards did hardware tricks to align it to 32-bits but not provide the actual RAM for the unused 8-bits. All modern hardware actually has the extra 8-bits and new graphics systems use it as the alpha or stencil buffer.

If you want to see this oddness, paint a pure colour gradiant (i.e. 0-100% blue, 0% red, 0% green) and count the bands. In 16-bit you'll see 32, in 32-bit you'll see 256... assuming your video card actually has an 8-bit DAC. Many of the older cards, especially on the PC, only had 6 or 7 bit DACs. Older LCD panels' display hardware could only display 5-7 bits of colour precision (I don't know about the newer ones, I haven't been paying much attention lately). Also note that the colour channels from the frame buffer each go through their own "gamma lookup table" (glut) before going to the DAC. This is used by Apple's ColorSync to adjust the monitor's output to match the standard(s). This GLUT is a table of 256 entries, each of which is 8-bits, IIRC. This means if its anything but linear then you may have duplicate entries when in 32-bit mode, resulting in fewer effective possible colours.

Pixel memory alignment is critical for processing performance. Early video subsystems would read on a byte or 16-bit word at a time and thus the individual channels had to be an even number of bits. Newer systems generally read one bus word (64 or 128 bits) at a time and get multiple pixels out of it. For CPU graphics, however, it is still far better to have the individual colour channels be arranged so that the processor can easily get at them and manipulate them -- i.e. individual byte or word per channel. If this is not done then the CPU has to "pack" and "unpack" pixels every time it wants to change them, which is wasteful and slow (and you think Aqua is bad now!!). Graphics hardware can have a special circuit to do this, and some has even had a memory interface where this is done auto-magically (i.e. the CPU writes one format and a different format is stored).

[ 04-12-2002: Message edited by: Programmer ]</p>

[quote]Originally posted by Bozo the Clown:
<strong>OK. I don't know about all the programming stuff going on here, but Eric is correct about the audio stuff.

CDs are recorded at 16bit/44.1kHz (not 48kHz), and this was specified as a minimal standard. 44.1kHz is just about double the frequency that we can hear at (up to 20kHz). In theory, you can get back the original analog signal, but it requires a lot processing power, and is never observed in reality. Newer audio "standards" (in quotes because they haven't really caught on) such as SACD and DVD-Audio go up to 24bit/192kHz.
</strong><hr></blockquote>

If you re-read my posts, you'll note than I never disagreed about the fact that CDs are 16/44.1, or that 24/96 audio makes some sense.

Rather, I didn't agree to Eric's claim that there's a strong necessity for 64bit audio.


[quote]<strong>
Why bother? Because the difference is audible. Probably not on a $40 boom box, but with good headphones or a high-end stereo you can hear the difference. The SACDs just sound more "natural" more like an good quality vinyl LP than do standard CDs.</strong><hr></blockquote>

I'm not arguing that.

Bye,
RazzFazz

[quote]Originally posted by RazzFazz:
<strong>
If you re-read my posts, you'll note than I never disagreed about the fact that CDs are 16/44.1, or that 24/96 audio makes some sense.

Rather, I didn't agree to Eric's claim that there's a strong necessity for 64bit audio.</strong><hr></blockquote>

I think audio should go to 32-bit floating point. This gives about 24 bits of precision, plus it handles way out-of-bound values... and all mixing software these days runs in floating point anyhow. 24-bit is an awkward size for the machines to deal with (same alignment issues as for graphics), but it is beyond the ability of the human ear to distinguish... most people can't detect the flaws in 48kHz/16bit. 24bit is 256 times more refined, and at a higher sampling rate it should be pretty much perfect to any human. Greater internal precision is useful for avoiding losses while mixing or doing processing on the audio, but the actual output doesn't need to be better.

Audio is a single channel of data, whereas video is 3 channels. 24-bit audio is kind of like 72-bit graphics.

[quote]Originally posted by RazzFazz:
<strong>Argh, of course. I meant that people originally used 24 bit wide "true colors".
(Besides, you forgot the early "high color" video cards which had 15-bit-colors (5 bits per channel). Also, each palette entry in the Amiga was a 12-bit-color.)</strong><hr></blockquote>

I wasn't referring to that. I was referring to "<a href="http://www.webopedia.com/TERM/t/true_color.html" target="_blank">True Color</a>"(I misspelled it). as in 24-bit graphics in general.

[quote]Originally posted by RazzFazz:
<strong>No. They used 32 bits to store 24bit color values for alignment reasons. Cf. Programmer's comment above.</strong><hr></blockquote>

What I meant was: "I have no of why they decided to reserve the last quarter of the byte for alternate channels/maps instead of just using all 32 bits for color".

[quote]Originally posted by RazzFazz:
<strong>Either you accidentally called a vinyl record a laserdisc, or you just didn't make a lot of sense. Laserdiscs are digital.</strong><hr></blockquote>

No they're not. laserdiscs are(Or at least were) 100% analog. they're optical like CDs(To increase ruggedness and media lifespan) and analog like film and records(To increase recording quality). although some of the most recent laserdiscs have alternate digital audio tracks. in addition to the analog tracks. but the video is still analog.

[quote]Originally posted by RazzFazz:
<strong>That's still 40 bits headroom, which is still completely unrealistic.
Have you ever seen anybody use more than 100% headroom?

And again, while the tech stuff get's better all the time, our ears don't.</strong><hr></blockquote>

Like I said. heavy editing can lead to heavy damage. and more overhead allows you to do more damage without anyone noticing.


Eric,

[ 04-12-2002: Message edited by: Eric D.V.H ]</p>

[quote]Originally posted by RazzFazz:
<strong>Eric, regarding pixel formats and RGB555, RGB565 and RGB888, you might want to take a look at this stuff:

<a href="http://grafi.ii.pw.edu.pl/gbm/matrox/ramdac.html" target="_blank">http://grafi.ii.pw.edu.pl/gbm/matrox/ramdac.html</a>
<a href="http://www.americanpredator.com/downloads/information/Video815E.pdf" target="_blank">http://www.americanpredator.com/downloads/information/Video815E.pdf</a>
<a href="http://www.law.emory.edu/fedcircuit/aug2001/00-1257.wp.html" target="_blank">http://www.law.emory.edu/fedcircuit/aug2001/00-1257.wp.html</a>

(Look for "direct color".)

</strong><hr></blockquote>

Hmm. I guess I was wrong. um oops.


Eric,

[quote]Originally posted by RazzFazz:
<strong>Are you pulling my leg or something?
You can't be serious here, can you?
Now one bit is supposed to be "whole byte size" because 8 divided by 8 is 1?</strong><hr></blockquote>

Yup. it's perfecly valid.

[quote]Originally posted by RazzFazz:
<strong>What do you mean?
Of course they are just bytes (we're talking about DACs and VRAM here, not files, BTW, even though the situation is the same there), but that's of course true for anything stored anywhere inside your computer. The difference is that they are interpreted in different ways, depending on whether they are direct or indexed colors.</strong><hr></blockquote>

What I mean is that actual palettized colors are stored in precisely the same manner as nonpalettized colors aside from the header dictating the reassignments of what the synthesizer is supposed to interpret a certain binary value as.

[quote]Originally posted by RazzFazz:
<strong>The difference between palettized colors and direct colors is that the former ones are translated using the color lookup table, and the corresponding values from the CLUT are then passed on to the RAMDACs. Direct colors, on the other hand, are passed straight to the DACs.
For example, in 8-bit-mode, each pixel can be any one of 256 possible colors stored in the CLUT. Each one of the 256b CLUT entries contains three bytes, one each for red, green and blue.
So color no. 1 might translate to (0,0,255), meaning bright blue, whereas color 15 might translate to (255,0,255), meaning violet. That way, your palette contains 256 colors out of 16.7mio., but you can only ever have at most 256 of them on your screen simultaneously.</strong><hr></blockquote>

Like I said.

[quote]Originally posted by RazzFazz:
<strong>No, that happens because your flipper overwrites CLUT entries with his own values, and suddenly the pixel colors translate to different ones than before (i.e. color no. 1 might now have become (63, 63, 63) or dark grey). Since the still "thinks" color no. 1 is bright blue, all bright blue areas on the screen surrounding the game turn into dark grey.</strong><hr></blockquote>

Like I said.

[quote]Originally posted by RazzFazz:
<strong>Read the links I mentioned above, I hope they'll clear some things up.</strong><hr></blockquote>

They sure did.

[quote]Originally posted by RazzFazz:
<strong>What part of it do you fail to understand?

Imagine a 16 bit color value in VRAM:
xxxxxxxxyyyyyyyy
--1 byte--1 byte

If the graphics card wants to put this on screen, it interprets it in the following way:

rrrrrggggggbbbbb
--red-green-blue

Example:
Let's assume a value of 52647 at some given address in VRAM. In binary representation, this is:

1100110110100111

Now, when the graphics card reads that value, it takes the first 5 bits and sends them to the red DAC, then sneds the next 6 bits to thw green DAC, and finally the remaining bits to the blue DAC:

Red: 11001 = 25
Green: 101101 = 45
Blue: 00111 = 7

In a hypothetical 16 bit indexed color mode, the graphics card would look up the 52647th entry in the color lookup table, and then load the individual DACs with the values stored there.

Got it?</strong><hr></blockquote>

When I said that(Prior to perusing the links you gave). I understood the above perfectly. I just thought it was all poppycock.


Eric,

[quote]Originally posted by Programmer:
<strong>Eric, I'm soSNIPPEDnd a different format is stored).</strong><hr></blockquote>

The only reason I was arguing was because. in the absence of any verifiable proof. like RazzFazz's links and your gradient striation counting trick. I couldn't except something so silly sounding.

(So THAT'S the reason why the "Thousands of Shades of Gray" and "Millions of Shades of Gray" modes weren't any different. and why my beautiful, ditherless 24-bit texture maps would always be screwed up by dithered 8-bit bump maps as a result )

Eric,

[quote]Originally posted by RazzFazz:
<strong>I didn't agree to Eric's claim that there's a strong necessity for 64bit audio.</strong><hr></blockquote>

[quote]Originally posted by Programmer:
<strong>I think audio should go to 32-bit floating point. This gives about 24 bits of precision, plus it handles way out-of-bound values... and all mixing software these days runs in floating point anyhow. 24-bit is an awkward size for the machines to deal with (same alignment issues as for graphics), but it is beyond the ability of the human ear to distinguish... most people can't detect the flaws in 48kHz/16bit. 24bit is 256 times more refined, and at a higher sampling rate it should be pretty much perfect to any human.</strong><hr></blockquote>

Yeah. but 32-bit only affords about a 33% safety net over 24-bit for editing/mixing. as opposed to the much larger 100% and 170% safety nets for 48-bit and 64-bit audio(Respectively).

[quote]Originally posted by Programmer:
<strong>Greater internal precision is useful for avoiding losses while mixing or doing processing on the audio, but the actual output doesn't need to be better.</strong><hr></blockquote>

Yes it does. the professionals that make the mix's need 48-64-bit digitizers so they have _something_ to work with. and as hardware downsampling/dithering can't possibly compare to the hand downsampled mix the audience will hear. those professionals also need 48-64-bit synthesizers to go with. and these professionals will be using Macs. and as you can perceive the extra 16-32 bits(If not consciously. then a deeper. but still perceived level) of quality. you might as well bump up the I/O on normal Macs. for music lovers, garage bands, gamers and numerous others. or maybe make it a BTO option. and let them decide.

Eric.

And as for whether or not a 64-bit CPU is needed for 48-64-bit video. even with quarter-byte(Or tri-byte in the case of even 64-bit bytes) video. my opinion is still yes.

Assuming a 48-bit byte of video data had to be passed through the integer unit of a 32-bit CPU in 16-bit long chunks. it could only eat through two of them in a cycle. thus bringing back that nasty two-cycles-per-pixel penalty. whereas the integer unit of a 64-bit CPU would happily take all three pieces in one cycle.

For this reason. the need for the G5 to be 64-bit(Which it already is ) in order to properly use both 48-64-bit audio AND video still stands as before.

Eric,

[quote]Originally posted by Eric D.V.H:
<strong>
No they're not. laserdiscs are(Or at least were) 100% analog. they're optical like CDs(To increase ruggedness and media lifespan) and analog like film and records(To increase recording quality). although some of the most recent laserdiscs have alternate digital audio tracks. in addition to the analog tracks. but the video is still analog.
</strong><hr></blockquote>

Could you provide a link or something? I find this a little hard to believe. How would you store analog data on optical media?

EDIT: Never mind, looked it up myself. They indeed seem to have analog tracks. My apologies. Still wondering how this is stored optically, though... :confused:


[quote]<strong>Like I said. heavy editing can lead to heavy damage. and more overhead allows you to do more damage without anyone noticing.
</strong><hr></blockquote>

And 40 bits of overhead give you a little more than 1 trillion operations on a single sample before you have rounding errors. Can anyone say overkill?


[quote]<strong>
What I mean is that actual palettized colors are stored in precisely the same manner as nonpalettized colors aside from the header dictating the reassignments of what the synthesizer is supposed to interpret a certain binary value as.
</strong><hr></blockquote>

And your point was?


[quote]<strong>
Yeah. but 32-bit only affords about a 33% safety net over 24-bit for editing/mixing. as opposed to the much larger 100% and 170% safety nets for 48-bit and 64-bit audio(Respectively).
</strong><hr></blockquote>

It seems to escape you that the the resolution grows exponentially with bit depth.
With 24 bit audio, you can distinguish 2^24=16.8mio levels of amplitude ("sonic pressure"?). Adding another 8 bits doesn't just add 5.6mio (one third of 16.8mio) to that number, but rather multiplies it by 2^8=256. 64 bit audio would multiply the number by more than one trillion.


[quote]<strong>
Yes it does. the professionals that make the mix's need 48-64-bit digitizers so they have _something_ to work with. and as hardware downsampling/dithering can't possibly compare to the hand downsampled mix the audience will hear. those professionals also need 48-64-bit synthesizers to go with.
</strong><hr></blockquote>

48bit digitizers? As in 48 bit ADCs? I don't think something like that even exists in the audio field.

Also, it would be nice if you could provide a link or anything that hints towards any existing piece of audio gear that has 48 or 64 bits of internal resolution.


[quote]<strong>
And as for whether or not a 64-bit CPU is needed for 48-64-bit video. even with quarter-byte(Or tri-byte in the case of even 64-bit bytes) video. my opinion is still yes.
Assuming a 48-bit byte of video data had to be passed through the integer unit of a 32-bit CPU in 16-bit long chunks. it could only eat through two of them in a cycle. thus bringing back that nasty two-cycles-per-pixel penalty. whereas the integer unit of a 64-bit CPU would happily take all three pieces in one cycle.
</strong><hr></blockquote>

Did you actually read my previous posts at all?
I hate to repeat myself, but as I already said at some point earlier in this thread, AltiVec can do exactly that, and can even do it for two such 64-bit-pixels at a time, in a single cycle, right now, with the current G4. This is exactly what it excels at.

Bye,
RazzFazz

[ 04-12-2002: Message edited by: RazzFazz ]</p>

[quote]Originally posted by Eric D.V.H:
<strong>
Yeah. but 32-bit only affords about a 33% safety net over 24-bit for editing/mixing. as opposed to the much larger 100% and 170% safety nets for 48-bit and 64-bit audio(Respectively).
</strong><hr></blockquote>

As Razz has already pointed out, you have missed the fact that adding bits exponentially increases the data range. Going from 16-bit samples to 32-bit float samples increases the precision by a factor of 25600%, and it lets you represent very large and very small values precisely. This should be more than sufficient for any input/output, although heavy processing might use larger internal formats to avoid computational errors.

I'm even a little skeptical if current technology allows equipment to be built (at sub-million dollar prices anyhow) that doesn't introduce noise caused by the circuitry at the level of 24-bit percision.

Note that a 5.1 audio signal at 32-bits per channel would be 192-bits per sample.