• Welkom bij Audiofreaksforum, Audio, Hifi, Luidsprekers, Buizen. Graag inloggen of registreren.
 

Cd to Flac

Gestart door Allagamma, 2 juni 2024, 14:56:06

Vorige topic - Volgende topic

Heintje

22 december 2024, 12:10:30 #30 Laatste wijziging: 22 december 2024, 12:17:24 door Heintje Reden: Corrigeren van de spellingcontrole
Meer in lekentaal:
Het "rippen" van een bestand houdt in dat het van de originele drager (bv. een CD) af wordt gelezen en opgeslagen op een mediadrager (bv. een harddisk). Voor correct "rippen" moet het resultaat bit-gelijk zijn aan het origineel.
Een CD-Rom drive (of iets anders wat je gebruikt om de CD af te spelen) leest eerst de inhoudsopgave ("is dit een CD? Of een DVD? Of iets anders?) en gaat daarna op de juiste plek (waar de bestanden zouden moeten staan) op basis van wat hij in de inhoudsopgave heeft gezien, de bestanden lezen op een gepaste uitleessnelheid.
Daarbij wordt begonnen op de hoogste snelheid die de drive aankan en die past bij het type bestand. Ook wordt die snelheid alléén gehandhaafd als de computer en het opslagmedium snel genoeg zijn om de datastroom correct te verwerken. Dat laatste komt nu nauwelijks meer voor, maar een jaar of 10 geleden schakelde de uitleessnelheid vaak omlaag omdat het moederbord de aangeboden datastroom niet snel genoeg op de (toen nog vaak traag type IDE) harddisk kwijt kon.
Als ergens iets niet lukt bij het uitlezen (in de groepjes databits zit telkens een controle-bit opgenomen, soms geeft dat aan dat er een foutieve uitlezing heeft plaatsgevonden), schakelt de drive terug naar een lagere uitleessnelheid en leest hij ook de sector met de fout uitgelezen data meermaals uit. Als dat het probleem niet verhelpt, krijg je een foutmelding en is het rippen op dat moment mislukt. Dan verwijder je de CD, je maakt hem goed schoon en je start het rippen opnieuw. Als je meer wil weten zoek je op "parity bit".
Het bovenstaande gaat dus over de uitleessnelheid van het rippen: als het lukt op hoge snelheid is het prima, als je het toerental van de CD erg hoort terugvallen kan de drive meestal ergens iets niet betrouwbaar uitlezen.

Als je alles correct instelt voor het rippen, wordt het bestand opgeslagen in de originele, bit-gelijke versie. Dat kost echter nogal wat ruimt, denk dan aan 800 MB voor een CD. In het IDE-harddisk tijdperk hád je die ruimte niet beschikbaar, dus dan werd er gecomprimeerd opgeslagen. Iedereen kent de term "een bestand zippen": je activeert software die kijkt of het bestand slimmer kan worden opgeslagen waardoor de benodigde opslagruimte kleiner wordt: als in een bestand 10.000 "nulletjes" achter elkaar staan, word het bestand kleiner als je niet 10.000 "nullen" opschrijft, maar een code ertussen zet "hier stonden 10.000 nullen". Aan zoiets kun je denken.
Kenmerkend voor het "zippen" van bestanden is dat je ze vóór gebruik zelf actief moet "un-zippen", waarna je het originele, bit-gelijke bestand terug krijgt. Het audio-equivalent van "zippen" is "FLAC-cen": je stelt de rip-software zo in dat er na het rippen geen origineel bestand op je harddisk terecht komt, maar een gecomprimeerd bestand in het FLAC-formaat.

Als je een computer gebruikt voor het afspelen van een FLAC-bestand, gaat dat meestal meteen goed: de computer ziet dat het een FLAC-bestand is en de-comprimeert het bestand vóór (en in de praktijk tijdens) het afspelen. Omdat de computer tegenwoordig processorkracht genoeg heeft, gaat dat qua processorkracht "ongemerkt". Het de-comprimeren van het FLAC-bestand veroorzaakt echter óók timing-problemen naar de datastroom die wordt gebruikt voor het afspelen van het bestand én de voedingsspanning van de computer krijgt extra verstoringen door het de-comprimeren. Daarom gaan er stemmen op die aanbevelen om géén gecomprimeerde bestanden te de-comprimeren tijdens het afspelen, omdat dat bij hen een hoorbaar verschil oplevert. Degenen die dit ervaren comprimeren zelf dus geen bestanden, ook omdat ze opslagruimte genoeg ervoor over hebben voor ongecomprimeerde opslag.

Als je een CD brandt om af te spelen op een CD-speler, geldt doorgaans dat een CD-speler niet kan omgaan met gecomprimeerde bestanden. Als je gaat voor probleemloos afspelen in de originele kwaliteit, brand je dus géén CD's met gecomprimeerde bestanden (dus niet in FLAC-formaat).

Een apart verschijnsel is een streamer: elke streamer is eigenlijk een computer die bestanden kan omzetten in geluid. Daarbij kan dat bestand afkomstig zijn uit jouw eigen muziekverzameling (mits die bestanden geript klaarstaan) of vanaf een muziekdienst op internet (bv. Tidal, Qobuz, Spotify enz.). 
Het hangt van de streamer af welke bestandsformaten hij kan verwerken en welk gehoormatig resultaat de streamer daarbij levert.

Qua bestandsformaten zijn er twee soorten: lossy en lossless:
- lossless: na decomprimeren ontstaat het bit-gelijke originele bestand, dus alsof er nooit werd gecomprimeerd.
Voorbeeld van zo'n formaat is FLAC. Bij lossless comprimeren is het gecomprimeerde bestand in de praktijk tot 20% kleiner dan het originele bestand.
- lossy: na decomprimeren ontstaat een muziekbestand wat bij het afspelen ongeveer zo klinkt als het originele bestand. Sommige details die door ons gehoor worden gemaskeerd, worden door de comprimeer-software uit de muziek gehaald "omdat we dat toch niet zullen horen". Het hangt van de instellingen van de rip-software af hoer groot het uiteindelijke bestand is en wat het gehoormatige resultaat is. Een lossy bestand klinkt dus nooit zoals het originele bestand, maar lijkt daar wel op.
Voorbeeld van een lossy bestandsformaat is MP3. Bij MP3-coderen kan het bestand tot wel 80% kleiner worden.

Wim72

Wat is het verschil tussen FLAC en ALAC en wat heeft de voorkeur!


Heintje

Ze zijn qua resultaat en klank gelijk, alleen van verschillende (software/licentie-)fabrikanten.

Rogers Hifi

Citaat van: Vincent Kars op 21 december 2024, 20:18:13
Citaat van: Kurt1970 op 21 december 2024, 19:11:10Sneller lezen kan dan weer wel een oplossing zijn om hick-ups in een cd te omzeilen, omdat er net minder informatie gelezen wordt.

Over onzin gesproken.....

dBpoweramp geeft gewoon vol gas. Uiteraard leest het alle samples en berekent het de MD5. Die gaat naar AccurateRip en als de MD5 klopt dan is er uiteraard geen enkele rede om op een lagere snelheid te gaan lezen.
Bij mijn weten detecteert dBpoweramp C1 and C2 errors (net als EAC of CUETools), dan gaat de snelheid omlaag en wordt er een retry gedaan.





Klopt helemaal.

renewouters

Citaat van: Kurt1970 op 22 december 2024, 11:57:32Sla die op als WAV, en doe vervolgens een binary compare.

Strikt genomen kan dat niet. De WAV (of AIFF) file is een reeks van 16 bit / 2 octets samples. Op een audio CD wordt iedere 8 bits uitgebreid met extra bits tot een reeks van 14 bits zodat foutcorrectie kan worden gedaan (Reed-Solomon, CIRC). Die 6 extra bits worden al verwijderd in de CD-speler door de error-correction decoder. Dus als je binary compares gaat doen vergelijk je al met min of meer bewerkte data.

Kurt1970

Dat bedoelde ik niet. Ik verwees naar 't feit dat als je een slechte CD (met krassen) gaat rippen op hoge en lage snelheid, dat de kans groot is dat het resultaat verschillend is, ook al geven ze beiden aan goed geript te zijn. Maw, een binary compare op de WAVs.

Vincent Kars

Citaat van: Kurt1970 op 25 december 2024, 14:16:57de kans groot is dat het resultaat verschillend is, ook al geven ze beiden aan goed geript te zijn
Je bedoelt dat 1 en dezelfde CD
geript op lage en op een hoge snelheid binair verschillen maar dat AccurateRip beweerd dat beide bitperfect geript zijn?
M.a.w. volgens you deugt AccurateRip niet?

Heintje

Ik denk dat Kurt1970 gelijk kán hebben!
Als een "te snelle" rip uitleesfouten bevat, kán het zo zijn dat stomtoevallig de paritybits over alle bytes kloppen, zodat er geen aanleiding is tot vertragen/teruglezen.
Een méér correct uitgelezen "trage" rip zal dan terecht óók géén afwijkende paritybits vertonen, zodat beide rips als "accuraat" worden bestempeld, maar tóch inhoudelijk verschillen. Tijdens het afluisteren zal zo'n qua resultaat fors afwijkende byte waarschijnlijk (onhoorbaar) worden genegeerd door de software, die het gat opvult middels interpolatie naar het volgende byte.
Of zo.  8)

Vincent Kars

Citaat van: Heintje op 25 december 2024, 22:10:31Als een "te snelle" rip uitleesfouten bevat, kán het zo zijn dat stomtoevallig de paritybits over alle bytes kloppen, zodat er geen aanleiding is tot vertragen/teruglezen.

Ik vrees dat dit een prachtige beschrijving is van hoe MD5 niet werkt.

Citaat van: Heintje op 25 december 2024, 22:10:31Tijdens het afluisteren zal zo'n qua resultaat fors afwijkende byte waarschijnlijk (onhoorbaar) worden genegeerd door de software, die het gat opvult middels interpolatie naar het volgende byte.
Een CD speler kan interpoleren
Maar als we het hebben over een rip, dan is er uiteraard geen sprake meer van interpolatie.

Citaat van: Heintje op 25 december 2024, 22:10:31Of zo.
Of niet.

Wim72

Ik rip altijd met mediaspeler maar daar kun je de snelheid van het rippen niet instellen en gaat dus zo snel als dat het systeem toelaat.
Moet ik anders gaan rippen met andere software?

Kurt1970

Citaat van: Vincent Kars op 25 december 2024, 16:56:27
Citaat van: Kurt1970 op 25 december 2024, 14:16:57de kans groot is dat het resultaat verschillend is, ook al geven ze beiden aan goed geript te zijn
Je bedoelt dat 1 en dezelfde CD
geript op lage en op een hoge snelheid binair verschillen maar dat AccurateRip beweerd dat beide bitperfect geript zijn?
M.a.w. volgens you deugt AccurateRip niet?
AccurateRip geeft dan iets aan van een juistheid van in de 90%, als ik me goed herinner.
Ik schrijf enkel neer wat ik max 10x op +1000 CDs heb voorgehad.