24-bit audio is obviously a noticeable improvement even on $150 headphones. I don't know why you think that. Similarly, 4k Blu-ray is obviously vastly superior to crappy compressed streams from Netflix or YouTube.
> 24-bit audio is obviously a noticeable improvement
16-bit is (IIRC) 96 dB of dynamic range, going from well below human perceptual noise level to above damage threshold.
24-bit is good for headroom when recording/mixing but useless for listening.
If there's any difference between a 16-bit and a 24-bit version it's either because they're actually not the same (different mixing/mastering^) or they're just poorly mixed/mastered from the start and don't use the full 16-bit (or 24-bit for that matter) dynamic range: if you by and large use only 2/3 of the bits to actually convey a signal change then it may say 16-bit on the tin but it's actually 10-bit or something, (and for 24-bit it's only using... 16-bit!) and the remainder bits are just wasted space.
^ I find that quite frequent on vinyl vs digital: vinyl sounds better not because of some inherent property of the medium but because the mastering (and sometimes even the mixing) is simply not the same, presumably because it doesn't cater for the same audience/use case (vinyl at home for amateurs/enthusiasts/audiophiles, digital for a much wider variety of users, listening conditions, and listening hardware)
> 24-bit audio is obviously a noticeable improvement even on $150 headphones
Not going to question your subjective experience, but I do not think most people will hear any difference between 16 and 24 bit playbacks under normal conditions, even with fancy headphones.
"120dB is greater than the difference between a mosquito somewhere in the same room and a jackhammer a foot away.... or the difference between a deserted 'soundproof' room and a sound loud enough to cause hearing damage in seconds.
16 bits is enough to store all we can hear, and will be enough forever." [1]
"
It's true that 16 bit linear PCM audio does not quite cover the entire theoretical dynamic range of the human ear in ideal conditions. Also, there are (and always will be) reasons to use more than 16 bits in recording and production.
None of that is relevant to playback; here 24 bit audio is as useless as 192kHz sampling. The good news is that at least 24 bit depth doesn't harm fidelity. It just doesn't help, and also wastes space.
"
> Not going to question your subjective experience
Read enough glowing product reviews from "audiophiles" on nonsense like $100 electrical sockets and $75 Ethernet cables and you'll start to question everything.
> 24-bit audio is obviously a noticeable improvement
Audio quality is famous for having an extremely strong placebo effect. Unless you did the test double blinded, your anecdote has a good chance of being wrong.
It isn't obviously noticeable when 99.9% of people could not tell the difference. Take Pet Sounds which was mixed in mono onto analogue tape, hiss and all. Most people do not have magic ears.
I thought I'd read studies on this, but it turns out it was on sample frequency rather then bit depth.
However, seeing as in audio bit depth only affects dynamic range, you'd have to be listening to something with an extreme dynamic range to hear it. I can see why higher bit depth is useful in recording, but not in playback.
> The extra dynamic range helps bypass bad mastering.
I'm not an audio engineer by any means, but I'm not sure that sentence makes sense. Mastering is what produces the final audio output - if you take a badly compressed master it's not going to matter if you export it to 16 or 24 bit.
>Nor can anyone hear the difference between a 16bit and a 24bit file, all else being equal.
While we don't know the exact dynamic range of human hearing, we do know it to be above 96dB.
Either way, using these 96dB in 16bit requires careful mastering.
With CDs, it is not possible to e.g. make a song quieter than the others in the CD without losing this 96dB range. There's no "ReplayGain" metadata in the discs; the format is aged and not fancy at all.
The mastering would have to be basically non-existent for it to use a dynamic range larger than available in 16bit, and would mean noone would ever hear the quieter parts.
If we're talking unmastered recordings for archival, yes 24bit is very useful. For final mastered copies released for listening it's completely untrue that 16bit doesn't offer enough dynamic range.
The way the “loudness wars” work is by reducing the dynamic range to be far narrower than what’s available at 16bit, which gives the impression of loudness even though the loudest sounds are no louder.
Lets say the mastering process compresses the recording extremely to a 42dB (8bit) range - outputting that to either 16 or 24 bit will make zero difference. The audio will still have a dynamic range of 42dB.
Surprised I had to go down this far to find this. Clockmaker's 4 / watchmaker's 4 is an aesthetic or balance thing more than a historical vestige. Source: own an Omega De Ville Hour Vision
But seriously -- wine should have equal performance to running a program "natively" on windows because it essentially is running the program natively, just with different system DLLs that call back to the linux kernel instead of the NT executive.
Their implementation may be slightly slower in places, but it's not a problem inherent to Wine itself, and could always be fixed.
I know there's a stigma against running win32 apps on linux, and possibly rightly so, but there really isn't a reason why Wine couldn't be a legitimate runtime environment for linux. You can make 100% open source software that targets Wine, and never needs to use or link to proprietary software.
Wine has even been ported to architectures where there have never been native windows ports, like the ppc64le port of Wine.
(Wine/win32's binary interface is also easier to intercept and automatically translate/emulate calls for non-native architectures, which is the basis of WoW64 and x86 on ARM emulation, and in Wine land, projects like Hangover https://github.com/AndreRH/hangover )
> wine should have equal performance to running a program "natively" on windows
That is not guaranteed. Windows programs and Win32 APIs are writting for and optimized to run on the the NT kernel which has different perfomance characteristics from the Linux kernel. Some example:
- Wine needs to emulate a case-insensitive filesystem on top of a case sensitive filesystem, which is less efficient thatn using a filesystem / kernel FS layer that is designed for this.
- Some locking primitives are different enough that Linux will need additional syscalls to let Wine reach the same perfomance when emulating the Windows ones [0]
Hmm, the filesystem thing would be a constant slowdown, and there is the locking/async primitives that are generally better on Windows, but at least those are being worked on, both for Wine and Linux in general. I kind of recall reading about an option for ext4 to allow optional case insensitive operation? Ah! Recently added it seems. Needs a pretty recent kernel and a format-time config option that I doubt any linux distro is using yet, though [0]
I just meant that, in general, Wine should be very close to as fast on Windows, since it can usually implement win32 DLLs without much emulation/translation needed. Excepting all the bits that do :-)
Now that it is becoming easier to run linux on windows and maybe macos, linux dev should make an effort to guarantee linux apps run REALLY fine on window and mac. That way instead of creating 3 native apps (win, mac and linux), you could simply target linux.
This won't work - developers will always target the biggest platform first and then complain that it takes to much work adapt the program to more portable APIs.
https://uscode.house.gov/view.xhtml?req=granuleid:USC-prelim...
reply