Bullshit.

Bitperfect is bitperfect. Dit zou je oveigens gewoon kunnen meten. Maar ik ben dan wel benieuwd. Waarin denk jij dat de ene bitperfect mode kan afwijken van een andere?
Dat was ook mijn gedachtengang. Maar theorie en praktijk zijn meestal niet hetzelfde. Er zitten (waarschijnlijk meerdere) verschillen in de implementaties. Ik zal met anekdotes de verschillen blootleggen. Je kent het verschil in prestaties al. Snelheid is extreem belangrijk voor geluid, en timing eveneens. Latency. Daar schiet windows tekort, en Linux ook.
Ik heb meer dan twaalf jaar tientalle Linux en windows systemen gebruikt. Op het moment dat ik overstapte naar FreeBSD merkte ik meteen dat de audio een stuk zuiverder klinkte, en kwalitatiever en gedetailleerder. Ik heb dan aan een paar mensen laten horen hoe FreeBSD zonder aanpassingen klonk, en deze mensen vonden ook dat het uitzonderlijk geluid had.
Dat het standaard beter klonk dan Linux, daar had ik geen enkele twijfel over, want ik had Linux jarenlang op dezelfde hardware gebruikt, en het verschil was
opvallend. Daarna heb ik exact dezelfde nummers op windows en op FreeBSD afgespeeld. FreeBSD was correct op alle toonhoogtes, maar bij windows werden bepaalde toonhoogtes versterkt, en het geluid klonk vervormd op windows10. Ik dacht dan dat dit voornamelijk door de resampling zou zijn. En dat ze toch hetzelfde (of heel gelijkaardig) zouden klinken indien ik bitperfect zou gebruiken.
Ik merkte meteen dat het niet zo makkelijk is om in windows al je audio apps bitperfect te laten gebruiken. Dus ik heb Ubuntu en Quod Libet genomen. Daar moet je maar één parameter ingeven en je hebt bitperfect audio. Wel het klonk werkelijk niet goed in vergelijking met FreeBSD, in exact dezelfde nummers in FLAC kwaliteit. Dus iedereen die mijn FreeBSD systeem beluisterd heeft was over de indruk van de geluidskwaliteit.
Maar ik zal nog een laatste duidelijke anekdote vertellen. Ik heb zowel FreeBSD op mijn desktop als op een netbook van 200 EUR. Die netbook gebruik ik nu als audiospeler ipv als computer. Maar mijn vader had een paar nieuwe CD's gekocht en was die aan het afspelen op zijn Pioneer DVD speler en hoogwaardige Infinity luidsprekers en Sony versterker. Ik had dezelfde CD's gedownload, niet eens in FLAC, maar in mp3 @ 320kbps. De Pioneer klonk werkelijk als een stuk crap in vergelijking met de goedkope en spotgoedkope netbook. En het was niet eens een subjectief verschil, de Pioneer klonk dof en het omgekeerde van een 'open geluid'. De FreeBSD netbook klonk loepzuiver, en het verschil in zuiverheid was GIGANTISCH. Mijn vader van 60 jaar kon het al meteen horen. En zijn oren zijn niet zo goed meer.
Je kunt je afvragen, hoe kan dit, dat het populairste besturingssysteem, 'windows', een product van één van de rijkste bedrijven ter wereld niet eens muziek kan afspelen? Wel je kunt je ook afvragen hoe het komt dat de meeste Python apps meteen in Linux werken na één commando, waar je twee uur kan troubleshooten in windows om deze simpele app te installeren. Of hoe komt het dat NginX, de beste webserver, na zoveel jaren nog niet deftig werkt in windows? Etc.
Je kunt je uiteindelijk de vraag stellen, zijn de werknemers van Microsoft, het rijkste bedrijf ter wereld, wel intelligent genoeg om iets nuttig/wenselijk te doen? Ik denk dat je hier een antwoord krijgt:
Microsoft Security Response Center, Why Rust for safe systems programming
https://msrc-blog.microso...safe-systems-programming/
'Now we’ll peek at why Microsoft thinks that Rust represents the best alternative to C and C++ currently available.'
License to thrill: Ahead of v13.0, the FreeBSD team talks about Linux and the completed toolchain project that changes everything
https://www.theregister.com/2021/03/10/the_state_of_freebsd/
'Is the FreeBSD team interested in using safer languages like Rust to improve security? Baldwin did not see this as the primary route to more memory safety. "One of the things I work on is a project at Cambridge called CHERI (Capability Hardware Enhanced RISC Instructions) that allow us to push special memory safety into the processor itself, so that you're able to have a much safer version of C itself.'
"And that will compose well with languages like Rust. It means we can take the safeness of the language and enforce it further down the stack than we currently can. So my personal bias is I think CHERI is going to be a better solution. FreeBSD is largely written in C and we were able to run the whole base system on CHERI. So we have all of that C code running as a safer C. I think that's the more likely future way to get memory-safe systems."
Als je nog steeds niet zou kunnen begrijpen dat 'talent van programmeurs' een
grote impact kan hebben in audioapplicaties:
https://meka.rs/blog/2021/10/12/freebsd-audio/