Software-update: FLAC 1.4.0

Versie 1.4.0 van de Free Lossless Audio Codec, oftewel FLAC, is verschenen. Dit geluidsbestandsformaat slaat data op zonder dat hierbij informatie verloren gaat, zoals dat wel het geval is bij bijvoorbeeld mp3, Ogg Vorbis en Opus. FLAC is beschikbaar voor diverse besturingssystemen en heeft meestal een extern programma nodig, dat als gebruikersinterface dient. In Windows kan dat bijvoorbeeld met ExactAudioCopy en foobar2000. De changelog voor deze uitgave laat de volgende veranderingen en verbeteringen zien:

Changes

As there have been changes to the library interfaces, the libFLAC version number is incremented to 12, the libFLAC++ version number is incremented to 10. As some changes were breaking, the version age numbers (see libtool versioning) have been reset to 0. For more details on the changes to the API, see the porting guide. The XMMS plugin and 'common' plugin code (used only by the XMMS plugin) are deprecated, they will be removed in a future release.

General:

• It is now possible to limit the minimum bitrate of a FLAC file generated by libFLAC and with the flac tool to 1 bit/sample. This function can be used to aid live streaming, for example for internet radio
• Encoding files with sample rates up to 1'048'575Hz is now possible. (Con Kolivas)
• Compression of preset -3 through -8 was slightly improved at the cost of a small decrease in encoding speed by increasing the precision with which autocorrelation was calculated (Martijn van Beurden)
• Encoding speed of preset -0, -1 and -2 was slightly improved
• Compression of presets -1 and -4 was slighly improved on certain material by changing the adaptive mid-side heuristics
• Speedups specifically targeting 64-bit ARMv8 devices using NEON were integrated (Ronen Gvili, Martijn van Beurden)
• Speedups for x86_64 CPUs having the FMA instruction set extention are added
• Encoding and decoding of 32-bit PCM is now possible

(Ogg) FLAC format:

• The FLAC format document is being rewritten by the IETF CELLAR working group. The latest draft can be found on https://datatracker.ietf.org/doc/draft-ietf-cellar-flac/
• The FLAC format document specifies no bounds for the residual. In other to match current decoder implementations, it is proposed to bound the residual to the range provided by a 32-bit int signed two's complement. This limit must be checked by FLAC encoders as to keep FLAC decoders free from the complexity of being to decode a residual exceeding a 32-bit int.
• There is now a set of files available to test whether a FLAC decoder implements the format correctly. This FLAC decoder testbench can be found at https://github.com/ietf-wg-cellar/flac-test-files. Also, results of testing hard- and software can be found here at https://wiki.hydrogenaud.io/index.php?title=FLAC_decoder_testbench.

flac:

• The option --limit-min-bitrate was added to aid streaming, see github #264
• The option --keep-foreign-metadata-if-present is added. This option works the same as --keep-foreign-metadata, but does return a warning instead of an error if no foreign metadata was found to store or restore
• The warning returned by the foreign metadata handling is now clearer in case a user tries to restore foreign metadata of the wrong type, for example decoding a FLAC file containing AIFF foreign metadata to a WAV file
• A problem when using the analyse function causing the first frame to have a wrong size and offset was fixed
• Fix bug where channel mask of a file is unintentionally reused when several files are processed with one command
• The order of compression-related commands is no longer important, i.e. -8ep gives the same result as -ep8. Previously, a compression level (like -8) would override a more specific setting (like -e or -p). This is no longer the case
• flac now checks the block-align property of WAV files to ensure non-standard WAV files (for which flac has no handling) are not mangled

metaflac:

• (none)

build system:

• MSVC and Makefile.lite build system files have been removed. Building with MSVC (Visual Studio) can be done by using CMake
• Various CMake improvements, especially for creating MSVC build files (Martijn van Beurden, martinRenou, CookiePLMonster, David Callu, Tyler Dunn, Cameron Cawley)
• Various fixes for MinGW (Martijn van Beurden, Cameron Cawley)
• Removed obsolete autotools macro's to silence warnings
• Fixes for FreeBSD PowerPC (pkubaj)
• Fixed some compiler warnings (Martijn van Beurden, Tyler Dunn)
• Fix building with uclibc (Fabrice Fontaine)

testing/validation:

• Addition of new encoder fuzzer, adding fuzzing for 8, 24 and 32-bit inputs
• Addition of new decoder fuzzer, adding coverage of seeking code
• Addition of metadata fuzzer, adding coverage of metadata APIs
• Various improvements to fuzzers to improve code coverage, fuzzing speed and stability
• Many changes to test suite to improve cross-platform compatibility (Rosen Penev)
• Windows CI now also builds the whole test suite
• Clang-format file added (Rosen Penev)
• Add warning on using v141_xp platform toolset with /MT (Martijn van Beurden, Paul Sanders)

libraries:

• Various seeking fixes (Martijn van Beurden, Robert Kausch)
• Various bugs fixed found by fuzzing
• On decoding, it is now checked whether residuals can be contained by a 32-bit int, preventing integer overflow
• Add check that samples supplied to libFLAC actually fall within the bps set
• Add checks when parsing metadata blocks to not allocate excessive amounts of memory and not overread
• Undocumented Windows-only utf8 functions are no longer exported to the DLL interface
• Removed all assembler and intrinsics code from the decoder to improve fuzzing, as they provided only a small speed benefit
• The bitwriter buffer is limited in size to 2^24 bytes, so it cannot write excessively large files. This is a backup in case another bug in this area creeps (back) in.
• The metadata iterations should now never return a vorbiscomment entry with NULL as an entry, now always at least an empty string is returned

documentation:

• Removed html documentation and generate man pages from markdown

Interface changes:

• libFLAC:
  • Addition of FLAC__stream_encoder_set_limit_min_bitrate() and FLAC__stream_encoder_get_limit_min_bitrate(), see github #264
  • get_client_data_from_decoder is renamed FLAC__get_decoder_client_data(), see github #124
  • All API functions taking a filename as an argument now take UTF-8 filenames on Windows, and no longer accept filenames using the current codepage
  • FLAC__Frame struct has changed: warmup samples are now stored in FLAC__int64 instead of FLAC__int32 types, and verbatim samples can now be stored in either FLAC__int32 or FLAC__int64 depending on whether samples fix the former or latter
  • The FLAC__StreamMetadata struct now has a tag, so it can be forward declared
• libFLAC++:
  • Addition of ::set_limit_min_bitrate() and ::get_limit_min_bitrate(), see github #264
  • All API functions taking a filename as an argument now take UTF-8 filenames on Windows, and no longer accept filenames using the current codepage
  • The ::FLAC__Frame struct has changed, see the libFLAC interface change.

Versienummer	1.4.0
Releasestatus	Final
Besturingssystemen	Windows 7, Linux, BSD, macOS, Windows 8, Windows 10, Windows 11
Website	Xiph
Download	https://github.com/xiph/flac/releases/tag/1.4.0
Licentietype	GPL

Reacties (53)

Een samplerate van 1.048.575Hz... Ik ben benieuwd naar een usecase daarvoor.

Is er iemand met verstand van codecs die kan uitleggen waarom de definitie überhaupt een maximum sample rate heeft?

Ik kan me voorstellen dat de sample rate ergens in de header van het bestand staat en dat het verder de vorm van de bytestream in de body niet uitmaakt.

Het zijn het aantal samplepunten die er per seconde worden bemonsterd. Deze is vast en moet gedefinieerd worden anders kan je simpelweg geen opname maken. Een samplerate van bijvoorbeeld 44.100 hz kan een maximum van 22.050hz weergeven, alles daarboven is kleiner dan de hoogste getal mogelijk en zal niet worden vastgelegd.

Voor de bitdiepte geld eigenlijk hetzelfde, met 16 bits kun je 65536 verschillende geluisniveaus vastleggen, van -32.767 tot +32.768 iirc. Die halvering (Nyquist Frequentie) gaat met bitrate uiteraard niet op.

Als je een eindeloos hoge samplerate zou hebben, heb je dus ook oneindig veel opslagruimte nodig, want dan zou je het gehele spectrum vastleggen. Theoretisch dus zelf radiozenders, telefoonmasten, satelieten etc etc. Er is alleen geen microfoon die dat allemaal kan vastleggen.

Een samplerate van 1.048.576 hz heeft geen enkel nut dan een theoretisch maximum, of een situatie waar er extern die van demultiplexing plaatsvind waardoor er meerdere streams in 1 signaal zitten.

Als je vleermuizen op wil nemen is een samplefrequentie van 240KHz nodig, maar voor hoorbaar geluid voor mensen is alles boven de 44.100 eigenlijk vrij nutteloos. Dat hadden ze ten tijde van de ontwikkeling van de CD al vrij goed in de gaten.

Mijns inziens zijn samplerates van 192KHz e.d. voor het eindproduct van audio/muziek complete nonsense. Voor opnemen is 24 bit en 192KHz wel nuttig, voor de nodige headroom bij het nabewerken.

Ik ben best wel een audiofiel maar mijn lokale muziek die ik naar FLAC omzet converteer ik nog altijd naar 16/44, simpelweg omdat hogere waarden niet waarneembaar zijn als een verbetering.

[Reactie gewijzigd door Fairy op 11 september 2022 14:56]

Voor de bitdiepte geld eigenlijk hetzelfde, met 16 bits kun je 65536 verschillende geluisniveaus vastleggen, van -32.767 tot +32.768 iirc. Die halvering (Nyquist Frequentie) gaat met bitrate uiteraard niet op.

Kleine toevoeging hierop. De bitdiepte heeft geen invloed op het harmonische gedeelte, alleen op het niveau van de ruisvloer. Hoe meer bits, hoe lager de ruisvloer.

Mijns inziens zijn samplerates van 192KHz e.d. voor het eindproduct van audio/muziek complete nonsense. Voor opnemen is 24 bit en 192KHz wel nuttig, voor de nodige headroom bij het nabewerken.

Correct, in ieder geval voor de bit diepte. Voor de samplerate kan 96kHz nog interessan zijn als je audio genereert (niet opgenomen audio afspelen dus, maar audio synthese), maar hoger dan dat is nutteloos (zolang de audio voor mensen is bedoelt).

Je kunt nu ook 1bit samplerate instellen , dus misschien voor DSD

DSD heeft een 1 bit sample depth (geen 1 bit sample rate) en een veel hogere samplerate. DSD kan dus niet in FLAC. Ik denk dat je de changelog verkeerd hebt begrepen, die 1bit/sample gaat over de uitvoer, dat is een nieuwe optie speciaal voor internet streaming waarbij wordt gezorgd voor een zekere minimale bitrate.

Er zijn mensen die audio samplen op 768kHz. Sommige mensen hebben het idee dat meer bitjes per definitie beter is. Aangezien het FLAC formaat het ondersteunt is besloten de software het ook te laten ondersteunen. Er wordt gewerkt aan het standardiseren van het FLAC formaat door de IETF en een deel daarvan is ervoor zorgen dat de referentie implementatie (de software die eveneens FLAC heet) alle mogelijkheden van het formaat ondersteunt.

Tot nu toe had het formaat dus ruimte voor samplerates tot 1.048.575Hz, maar de referentie software ondersteunde tot nu toe tot 655350Hz. Nu kan het dus (qua samplerates) alles waar het formaat ruimte voor heeft.

[Reactie gewijzigd door ktf op 11 september 2022 19:42]

Hoger is altijd beter!

Vanaf een bepaald punt is hoger niet meer beter. Volgens fourier heb je twee samples per periode nodig om het signaal exact te kunnen construeren. Dat betekent dat je met deze versie signalen tot 524 kHz natuurgetrouw kan "weergeven". Dat is zo'n enorme overkill. Zeker voor audio zit je dan al heel ver over het punt dat meer samples een betere weergave geeft. Zelfs bij een samplefrequentie van 192 kHz zit je daar al heel ver overheen.

Hoorbaar niet maar wel meetbaar en metingen voor in de wetenschap waarbij elk extreem detail een verschil kan maken in een betekenisvolle waarneming.

Ja, dat klopt, maar de vraag is of je dat gaat doen via een audiocodec als flac. Daar heb je software en apparatuur voor dat ontworpen is voor het hoogfrequente gebied.

Het was ook met een knipoog. 1 MHz, want daar ging het over is een leuke "grens" in audioland qua stabiliteit. De meesten horen de 20kHz top van het "officiële" Hi-Fi spectrum niet eens. Maar voor nerds wel lekker.
Zodra er converters zijn die alles tussen de 2 en 20 Hz echt strak "opnemen", dan gaan we echt vooruit.
(en van links naar rechts...)

Niet echt. De DAC moet ook die sample rate aankunnen anders luister je alsnog naar een interpretatie

Uiteraard!

Ga het zometeen installeren ff kijken op m’n Mac mini wat mn DAC er mee doet , heb zelf een Holo Audio MAY level 2 DAC

Beter waarvoor?

In ieder geval de afdeling marketing.

Er zit weinig geen marketing achter, want FLAC is vrij te gebruiken en open source onder BSD licentie....

[Reactie gewijzigd door Fairy op 13 september 2022 12:49]

Dat is lang niet altijd het geval.
Boven de 96KHz 24bit neemt de kans dat tijdens bewerken/mixen quantization errors ontstaan alleen maar toe. 48KHz 24bit is al ruim overkill op wat het menselijk gehoor kan waarnemen.

Dat is lang niet altijd het geval.
Boven de 96KHz 24bit neemt de kans dat tijdens bewerken/mixen quantization errors ontstaan alleen maar toe.

Hier ben ik wel benieuwd naar, kan je deze onderbouwen?

16 vs 24 bit heeft een voordeel, omdat je met 24 bit meer ruimte hebt om afrondingsfouten (quantization errors) weg te filteren (dither). Dit doen moderne DAC's ook door te upsampelen naar 32 of zelfs 64 bit. Indien een opname in 192/24 is opgenomen dan ontstaat de weg terug naar CD formaat juist meer afrondingsfouten. In heel veel opname studio's wordt nog lang niet altijd 192/24 opgenomen en is dat wel het geval dan is dat lang niet altijd beter voor de weergave op cd formaat of via tidal lossless.

Je haalt hier een aantal zaken door elkaar.

16 vs 24 bit heeft een voordeel, omdat je met 24 bit meer ruimte hebt om afrondingsfouten (quantization errors) weg te filteren (dither).

Dit is half correct. Bij hogere bitdieptes zijn er minder kwantiesatiefouten, maar dat heeft niets met filteren te maken. Dithering heeft ook geen directe relatie met de bitdiepte. Je kunt dither toepassen bij elke bitdiepte.

Dit doen moderne DAC's ook door te upsampelen naar 32 of zelfs 64 bit.

Het is natuurkunding niet mogelijk om een ruisvloer te hebben zachter dan 22 bit (ik ben niet helemaal zeker van dit getal, hier ergens in de buurt). Zolang je in het digitale domein zit heeft een hogere bitdiepte in theorie meerwaarde, maar dat is dus weg zodra je naar analoog gaat. Een DAC die 'zegt' 24-bit te halen haalt dat in de praktijk dus nooit.

Daarnaast heeft de bitdiepte vergroten helemaal geen zin, kwantisatieruis die er al was verdwijnt niet spontaan. Een DAC zal dus niet de bitdiepte vergroten (tenzij je het over iets van een Console hebt waarbij je audio gaat mixen ofzo).

Indien een opname in 192/24 is opgenomen dan ontstaat de weg terug naar CD formaat juist meer afrondingsfouten

Wil je deze dan nog eens uitleggen? Waar komen deze afrondingsfouten vandaan?

Als je afrondingsfouten hebt op 192/24 en je gaat downsamplen neemt dat toe. Voor het filteren van ongewenste ruis wordt al jaren upsampling toegepast om te ‘filteren’.

Edit: zowel op bit diepte als samplerate

[Reactie gewijzigd door i_like_scotland op 12 september 2022 18:07]

Sorry, hier kan ik niets mee. Kun je een praktisch voorbeeld geven waar afrondingsfouten toenemen en hoe de bitdiepte verhogen ruis filtert?

Lijkt mij toch duidelijk dat als je van 24 bit naar 16 bit gaat dat quantization errors en ruis toenemen. Daarnaast ben ik mij er van bewust dat je dither technisch gezien niet hoeft te gebruiken, maar ieder mastering product raad het voor een goed eindresultaat wel aan te gebruiken.

Lijkt mij toch duidelijk dat als je van 24 bit naar 16 bit gaat dat quantization errors en ruis toenemen.

Uiteraard, maar dat is niet wat je eerder zei. Jij stelde dat van een hogere samplerate / bitdiepte down samplen meer 'afrondingsfouten' oplevert dan van een lagere samplerate. Ik ben op zoek naar de onderbouwing van die stelling.

Ah helder, ik doelde op bits voor afrondingsfouten.
Samplerate niet naar mijn weten, maar als er over zo hoog mogelijk wordt gesproken dan kom je op bit en sample rate's van 96/24 of 192/24 uit.

Als je afrondingsfouten hebt op 192/24 en je gaat downsamplen neemt dat toe. Voor het filteren van ongewenste ruis wordt al jaren upsampling toegepast om te ‘filteren’.

Edit: zowel op bit diepte als samplerate

En met vet gedrukte doelde ik op het upsampelen van samplerate voor filters als nois shaping, niet zo zeer de oorzaak afrondingsfouten.

Misschien is het beter om hier een eind aan te breien, wat het allemaal wat offtopic, maar ik kan je nog steeds niet helemaal volgen

Het is zinloos om voor iets als noiseshaping eerst van 16-bit naar 24-bit te converteren en daarna weer terug (tenzij je bijvoorbeeld het signaal gaat verzwakken en daarna weer gaat versterken).

Als je een 16-bit signaal hebt zit daar een ruisvloer in op -96dBFS. Als je dit omrekent naar 24-bit blijft de ruisvloer even hard. Zelf als je met noise shaping in het 24-bit domein de ruisvloer onder die -96dBFS krijgt is hij weer net zo hard op het moment dat je terug converteert naar 16-bit.

Ik zeg ook niet dat je voor noise shaping naar 24 bit moet, daar refereer ik naar upsampling van de sample frequentie. Maar volgens mij praten we lang elkaar heen ;-)

Lol, dat is bijna genoeg om de vroegere radio Veronica op de AM radio band op te nemen maar dan het gehele uitgezonden RF signaal. Bijna, 538 kHz x 2 is net teveel volgens Nyquist maar toch wel illustratief hoe de techniek zich heeft ontwikkeld.

Een samplerate van 1.048.575Hz... Ik ben benieuwd naar een usecase daarvoor.

Lol, die rate acteert meer als een harde technische boundary dan dat die bedoelt is voor een practische toepassing.

Ikzelf hoor het verschil vanaf 128 kHz amper.

[Reactie gewijzigd door Bulkzooi op 11 september 2022 14:05]

Je bedoelt ws 128kbps bij lossy compressie, dat is iets anders 😊

Je bedoelt ws 128kbps bij lossy compressie, dat is iets anders 😊

Ach, da's lood om oud ijzer en kan nooit veel schelen.

Maar ik bedoelde zeker niet lossy. Of hoe lossy bedoel je eigenlijk?

Maar vanaf 192 kbps (fixed) ben ik aardig overtuigd dat ik amper verschillen hoor.

Er zijn ongetwijfeld audiofielen die 1'048'575Hz heel interessant vinden.

Numerologen ook. En Excel-freaks ook.

[Reactie gewijzigd door Bulkzooi op 13 september 2022 01:37]

Ach, da's lood om oud ijzer en kan nooit veel schelen.

Het is ongeveer hetzelfde als zeggen dat je het niet erg vind dat de snelheidslimiet op de snelweg lager wordt omdat je auto toch niet herder gaat dan 90pk. Het heeft met elkaar te maken maar er is geen 1:1 relatie.

Maar ik bedoelde zeker niet lossy. Of hoe lossy bedoel je eigenlijk?

Als er over kbps gesproken wordt is eigenlijk altijd sprake van lossy audio. En daarmee wordt bedoeld dat de codec in kwestie niet kan garanderen dat de output exact gelijk is aan de input.

Maar vanaf 192 kbps (fixed) ben ik aardig overtuigd dat ik amper verschillen hoor.

Dat ben ik met je eens, in de praktijk kan vrijwel niemand dat 😊

[Reactie gewijzigd door MerijnB op 13 september 2022 08:46]

Wetenschap misschien, iets anders zou ik me niet kunnen bedenken.

Dat was ook het enige dat ik kon bedenken, maar zelfs dan vraag ik me af of je dat dan gaat doen in het audio-domein.

Er zijn ongetwijfeld audiofielen die dit heel interessant vinden.

Waarschijnlijk voor DSD 1024. (DSD 5,6mhz) is voor DSD128. SACD dus.

DSD is een hoge samplerate met maar 1 bit als bitdiepte, hier bij flac gaat het over hoge samplerate bij 16 of meer bits, deze zijn niet te vergelijken.

Ik heb het niet specifiek over flac. DSD kan omgezet worden naar pcm. PCM weer naar flac.

[Reactie gewijzigd door Tourmaline op 14 september 2022 01:02]

Als je DSD omzet naar Pcm heb je geen bijzonder hoge samplerates nodig. DSD 128 past 'gewoon' in 192kHz Pcm.

DSD1024 is 44,1 x 1024 en past daar dus niet in. Misschien is dat voor DSD1024 naar pcm conversie en decoding.
"Encoding files with sample rates up to 1'048'575Hz is now possible. (Con Kolivas)" Dat is voor high resolution digital audio formats. Anders zou ik niet weten waar je het voor nodig zou hebben. DSD1024 is ongeveer PCM 32 bit. 64/768 is er ook nog. Of het er allemaal nog toe doet en hoorbaar is laat ik even in het midden. De hard- en software gaat ook steeds hoger...

[Reactie gewijzigd door Tourmaline op 14 september 2022 11:09]

Goed punt. Ik heb de details van DSD niet exact in mijn hoofd, maar is de prijs van DSD niet dat SNR bij hogere frequenties bijzonder slecht wordt?

Heb jij enig idee wat (bij bijvoorbeeld DSD1024) nog een reële frequency response is mbt noise floor?

Misschien heb je hier wat aan:

"The fact is, DSD is flat to 1/2 * (64*44100) = 1.411200 MHz. The
problem is, the (quantization) noise gets really loud up at that
frequency. But the signal (as opposed to noise) frequency response
itself is flat.

Contrast this with a linear PCM system in which the signal bandwidth
is also 1/2 of the sample rate, but the quantization noise power is
constant throughout that bandwidth. That's the main difference between
DSD and linear PCM - that the noise is "shaped" so that there is a
different amount of noise in different parts of the spectrum."

Zoals ik dit lees is het bij pcm constant in het hele frequentiebereik en fluctueert het bij dsd.
" the waste of noise DSD has in higher frequencies"

Ik lees op het web dat veelal bij 30khz een low pass filter wordt gebruikt vanwege de ruis in de hoge frequenties bij DSD. Er zijn wisselende berichten over DSD vs PCM. Ene keer klingt de DSD beter dan de PCM en nadersom. Veel zal ook afhangen van de mastering.

Traditional 1 bit DSD DACs suffer from a sharp build-up of the out-of-band noise. This noise is the consequence of using 1 bit Sigma Delta DACs and is intrinsic to the DSD process. This out-of-band noise is very strong and easily overloads sensitive analog amplifiers, causing them to distort the audio signal. For this reason, the out-of-band noise is typically filtered out using sharp analog filters set at 30-50kHz. Unfortunately, these filters introduce phase nonlinearities in the audio signal and slow down audio transients, defeating most of the benefits of the DSD"

de nieuwe dac's kunnen dit al aan:
Official Support USB and I2S up to DSD1024 and PCM1.536MHz sample rate.

[Reactie gewijzigd door Tourmaline op 14 september 2022 12:14]

"The fact is, DSD is flat to 1/2 * (64*44100) = 1.411200 MHz. The
problem is, the (quantization) noise gets really loud up at that
frequency. But the signal (as opposed to noise) frequency response
itself is flat.

Contrast this with a linear PCM system in which the signal bandwidth
is also 1/2 of the sample rate, but the quantization noise power is
constant throughout that bandwidth. That's the main difference between
DSD and linear PCM - that the noise is "shaped" so that there is a
different amount of noise in different parts of the spectrum."

Zoals ik dit lees is het bij pcm constant in het hele frequentiebereik en fluctueert het bij dsd.
" the waste of noise DSD has in higher frequencies"

Ja precies, dat is ook hoe ik het in mijn hoofd had.

Ik lees op het web dat veelal bij 30khz een low pass filter wordt gebruikt vanwege de ruis in de hoge frequenties bij DSD.

Bij DSD1024? Dat lijkt me erg laag, dan is het hele nut van die hoge samplerate weg? (even los of dat nut er al was of niet).

Ik lees vaak van 30khz t/m 50khz.......om de noise het hoofd te beiden in de hogere frequenties. Daarom klinkt DSD vaak ook niet beter dan pcm...

"For this reason, the out-of-band noise is typically filtered out using sharp analog filters set at 30-50kHz."

[Reactie gewijzigd door Tourmaline op 14 september 2022 16:47]

nou dat slightly improved bij compressie 8 is wel echt mini.

heb ff getest en het was echt maar een paar kb. op een hele cd is het wel een schokkende 20-30kb.

tuurlijk kleinere bestanden met dezelfde kwaliteit is beter maar ik had zelf iets meer verwacht. gelukkig merk je het verschil in encoding speed met een beteje goede pc totaal niet. ik heb een ryzen 5 2600 dus dat is al niet de meest snelle cpu.

[Reactie gewijzigd door Jeffrey2107 op 11 september 2022 14:18]

Flac is redelijk uit ontwikkeld, als er ook nog 'slight' in de changelog staat moet je niet teveel verwachten. Ik denk niet dat hier nog veel gewonnen gaat worden.

nee dat blijkt wel. gelukkig maar eigenlijk want anders ben ik elke keer mijn hele collectie opnieuw aan het encoden.

Het hangt ook af van de data. Een geluidsbestand met een toespraak kan veel beter gecomprimeerd worden dan een registratie van een live-concert.

Het is sterk afhankelijk van de content. Op 'high-res audio' waarin geen 'high-res content' zit, bijvoorbeeld audio die van een CD is 'geupsampled' naar 96kHz (wat verrassend veel gebeurd) zijn de verschillen makkelijk > 10%. Voor CD audio profiteert vooral muziek met slechts enkele instrumenten, vooral pianomuziek.

Zie bijvoorbeeld wat testresultaten hier. edit: de originele link bevatte een komma, dat gaat schijnbaar niet hier. Vervangen door een link naar het topic i.p.v. een dieplink naar de post zelf, zie post #94 voor de bedoelde resultaten.

[Reactie gewijzigd door ktf op 12 september 2022 09:46]

je testresultatenlinkje werkt niet lekker

Zoals altijd kun je hier losse compiles vinden zoals libFLAC.dll zodat je software die (nog) niet up-to-date is zelf kunt bijwerken. Ik gebruik dat bijv. voor eac3to.

in dit geval kwam de source code windows zip ook met de libflac dll.