AMD’s $499 Ryzen 7 1800X Beats $1700 i7 6950X with 1-Click OC on Air Cooling

https://www.adorama.com/ipxk1.html https://www.adorama.com/inkd810.html https://www.adorama.com/inkd7100.html

Which brings a slightly unrelated note: people seem to be blissfully unaware that you need less than 9mpix for a 12x9" 300 dpi print or that the zoom lens they bought with the camera has sharpness that effectively limits the resolution to 5-10, maybe 12 mpix if they are lucky. But megapixel count is easy to sell -> race for more megapixels -> smaller physical pixels -> more signal amplification needed -> more noise / general lower photo quality.

The complaint is not about adding the capability to all chips. It's about smoothing out the step function between consumer machines and professional workstations.

It's the same rationale for doing calculations in full 80-bit or 64-bit FP even if you don't need the full bits of precision -- if you start your calculations at your target precision, your result will have insufficient precision due to truncation, roundoff, overflow, underflow, clipping, etc. in intermediate calculations.

In theory, if you knew what your editing pipeline is, one could mathematically derive the starting headroom required to end up with acceptable error, but in practice that's probably a very risky proposition because 1) you don't know every intermediate calculation going on in every piece of software and 2) errors grow in highly non-linear ways, so even a small change in your pipeline might cause a large change in required headroom [1].

[1] https://en.wikipedia.org/wiki/Numerical_analysis#Generation_...

While people here like to quote that infamous looks-like-science-but-isn't Xiph video, the reality is that a lot of professional engineers absolutely can hear the difference.

If you have good studio monitors and you know what to listen for the difference between a 24-bit master and a downsampled and dithered 16-bit CD master is very obvious indeed, and there are peer reviewed papers that explain why.

Dither was developed precisely because naively interpolated or truncated 16-bit audio is audibly inferior to a 24-bit source.

Many people certainly can hear the effect of dither on half-decent hardware, even though it's usually only applied to the LSB of 16-bit data. From a naive understanding of audio a single bit difference should be completely inaudible, because it's really, really quiet.

From a more informed view it isn't hard to hear at all - and there are good technical reasons for that.

For synthesis, you don't want dither. You want as much bit depth as possible so you can choose between dynamic range and low-level detail. So 24-bit data is the industry standard for orchestral samples.

Digital samples can and will generate intermodulation distortion, quantization and other audio artifacts when mixed. Using 24-bit lessens or eliminates the effect versus 16-bit.

Experiments and results on this software are here: http://www.sonusparadisi.cz/en/blog/do-not-load-in-16-bit/

For mixed and mastered music, the ~120dB perceived dynamic range of properly dithered 16-bit audio is more than sufficient. If you're listening at sufficient volume for the dither noise floor to be higher than the ambient noise floor of the room, you'll deafen yourself in minutes.

For production use, the extra dynamic range of 24 bit recording is invaluable. You're dealing with unpredictable signal levels and often applying large amounts of gain, so you'll run into the limits of 16-bit recording fairly often. In a professional context, noise is unacceptable and clipping is completely disastrous. Most DAW software mixes signals at 64 bits - the computational overhead is marginal, it minimises rounding errors and it frees the operator from having to worry about gain staging.

You can probably get away with 16 bit recordings for a sample library, but it's completely unnecessary. Modern sampling engines use direct-from-disk streaming, so only a tiny fraction of each sample is stored in RAM to account for disk latency. The software used by OP (Hauptwerk) is inexplicably inefficient, because it loads all samples into RAM when an instrument is loaded.

(Tangentially: I wouldn't bother with ECC RAM for this application unless that were required by the rest of the hardware. Memory errors may slightly affect time to a converged solution, but it's rare that a flipped bit would actually cause a job to converge to a different solution.)

If you follow this very thread, you'll notice that another user already complained that "you need to pony up for a Xeon workstation if you need more than 64 GB."

Less sarcastically, what do people need >64 gigs for on a consumer desktop? I'm a dev and work on a pretty memory intensive service and don't need 128 gigs. Holding an entire double layer blu-ray in memory would only require 50 gigs.

I'm not holding my breath for ECC support. My thinking is that if it could run ECC RAM with the actual corrections enabled, they'd be talked about that as a selling point. I'd sure like it with the 32GB I have going into this build, but I just went with "G.SKILL F4-3000C15D-32GTZ TridentZ Series 32GB (2 x 16GB) 288-Pin DDR4 SDRAM DDR4 3000 (PC4 24000)" for now, with the idea that I'll get a second of the same kit in a couple of years when it's half the price of today.