Compressie bij CDs rippen?

[markvl]

Naar aanleiding van de geplande vergelijking tussen Squeezebox, AirPort en loopwerk wil ik eens vragen wat jullie gedachten over rippen met compressie zijn.

Mijn mening hierover:

Ik kan 3 redenen bedenken om CDs te rippen naar een PC.

1. Backup - als er iets met de CD gebeurt kun je een nieuwe copie branden
Hierbij is het uitgangspunt dat je 'lossless' copieert; anders verlies je informatie en dat probeer je nu net te vermijden.

2. CDs omzetten naar een MP3 speler
Dit is volgens mij de enige waarbij compressie nodig kan zijn omdat de speler geen wav (aiff voor Mackers) aankan, of omdat je meer bestanden op je speler wilt zetten dan er anders op kunnen.
En zelfs in dit geval kun je besluiten eerst lossless te rippen en daarna een copie naar .mp3 of zo te maken.

3. Spelen van muziek vanaf de PC, rechtstreeks via een soundcard of via een externe oplossing (Snazio, SB, AirPort, Roku, etc.)
Hier wil ik zelf de best mogelijke kwaliteit, en dus ook 'lossless'.

In dit topic wil ik geval 2. buiten beschouwing laten en me richten op 1. en 3.

Compressie in welke vorm dan ook dient om bestanden kleiner te maken, dus in feite om meer informatie op een schijf te krijgen.
Maar dat doe je eigenlijk omdat je schijfruimte beperkt is. En met de prijzen van harde schijven die nog steeds de goede kant uitgaan is dat steeds minder noodzaak.

In mijn geval heb ik 450 Cds 1-op-1 geript als .wav files, hiervoor heb ik ongeveer 270Gb aan ruimte nodig.
Ik heb nu 2 schijven van 250Gb in mijn fileserver zitten (waren +/- 100 euro per stuk), die grotendeels beschikbaar zijn voor muziek.
Voor mij was compressie dan ook absoluut niet nodig.
Bijkomende reden was dat mijn Squeezebox de wav files zonder enige bewerking kan doorsluizen naar mijn pre/pro.
Bij andere formaten is er of op de fileserver of in de Squeezebox weer een conversie nodig.
En "less <processing> is more <music>" is denk ik hier van toepassing.

Ik ben benieuwd wat jullie afwegingen zijn om al dan niet compressie te gebruiken, en in welke vorm dat dan is.

Groeten,
Mark

[Audiofiel]

2. CDs omzetten naar een MP3 speler
Dit is volgens mij de enige waarbij compressie nodig kan zijn omdat de speler geen wav (aiff voor Mackers) aankan, of omdat je meer bestanden op je speler wilt zetten dan er anders op kunnen.
En zelfs in dit geval kun je besluiten eerst lossless te rippen en daarna een copie naar .mp3 of zo te maken.

Met Mackers bedoel je waarschijnlijk Mac-gebruikers (vanwaar die -k-?).

Wat betreft WAV is het wel nuttig te vermelden dat dit enkel een container is. Een 'WAV' zegt feitelijk helemaal niets over het bestand, behalve dat er waarschijnlijk een audio-bestand in zit. Op de Macintosh is AIFF een meer gebruikte vorm.

Meer over WAV en AIFF wordt hier uitgelegd:

WAV (or WAVE), short for WAVE form audio format, is a Microsoft and IBM audio file format standard for storing audio on PCs. It is a variant of the RIFF bitstream format method for storing data in "chunks", and thus also close to the IFF and the AIFF format used on Macintosh computers. It takes into account some differences of the Intel CPU such as little-endian byte order. The RIFF format acts as a "wrapper" for various audio compression codecs. It is the main format used on Windows systems for raw audio.

bron: Wikipedia

Ik ben benieuwd wat jullie afwegingen zijn om al dan niet compressie te gebruiken, en in welke vorm dat dan is.

Ik wil geen compressie gebruiken omdat ik de hoogste kwaliteit wil halen. Aangezien ik echter niet alle >1100 CD's die wij hebben kan rippen naar AIFF of Apple Lossless wegens chronisch ruimtetekort, heb ik alleen de ongeveer 300 beste CD's weggeschreven door iTunes als Apple Lossless, de rest is MP3 192 Kpbs. Ik wil alle muziek direct ter beschikking hebben op alle Macs in huis om te gebruiken in (eigen) videomateriaal in iMovie en iDVD, als achtergrondmuziek met iTunes, om op de iPod te zetten of om een diavoorstelling mee af te spelen met iPhoto.

Op mijn 6 Gb iPod mini heb ik voor 90% Apple Lossless bestanden staan en die gebruik ik alleen op mijn Pioneer autoradio-adapter. Het verschil tussen AAC 128, MP3 en Lossless is op die autoradio voor mij duidelijk te horen, de eerste twee geven luistermoeheid, de laatste is goed om aan te horen. En dat is dan nu nog met de ingebouwde meegeleverde auto-speakers...

[Achiel]

Ik gebruik compressie simpelweg omdat ik de cd's rip puur voor het gemak. Muziekje als ik achter de pc zit, of om even op een cdrw te zetten voor in de auto. Alhoewel ik zowel in de auto als bij de pc geen slecht geluid heb is kwaliteit voor mij voldoende.

Veel ligt aan de manier van het rippen. Ikzelf gebruik het programma EAC http://www.exactaudiocopy.de/ in combinatie met LAME mp3 encoder http://www.chip.de/downloads/c1_downloads_13003295.html

De gebruikte encoderinstelling (het belangrijkste eigenlijk) in EAC is: -V 2 --vbr-new --add-id3v2 --pad-id3v2 --ta "%a" --tt "%t" --tl "%g" --ty "%y" --tn "%n"

Mocht je meer interesse hebben kan ik altijd helpen met het instellen van EAC i.c.m. Lame. Het kost even tijd om het maximale eruit te halen. EAC kan ook ongecomprimeerd rippen, het is sowiso het beste programma tot zover ik weet.

[J.A.F._Doorhof]

Opgeschoond, laten we aub on topic proberen te blijven.

[markvl]

Met Mackers bedoel je waarschijnlijk Mac-gebruikers (vanwaar die -k-?).

Mac + makkers 

Ruimtegebrek is inderdaad bij dergelijke hoeveelheden een iets groter (luxe- ) probleem.
Ik ga er trouwens wel van uit dat de Gb-per-euro verhouding van harde schijven/recordables de komende tijd flink harder zal stijgen dan die van de Gb-per-muziekdrager. Zeker met holografische technieken gaat het richting terabyte per schijf.

Ik gebruik compressie simpelweg omdat ik de cd's rip puur voor het gemak. Muziekje als ik achter de pc zit, of om even op een cdrw te zetten voor in de auto. Alhoewel ik zowel in de auto als bij de pc geen slecht geluid heb is kwaliteit voor mij voldoende.

Veel ligt aan de manier van het rippen. Ikzelf gebruik het programma EAC http://www.exactaudiocopy.de/ in combinatie met LAME mp3 encoder http://www.chip.de/downloads/c1_downloads_13003295.html

De gebruikte encoderinstelling (het belangrijkste eigenlijk) in EAC is: -V 2 --vbr-new --add-id3v2 --pad-id3v2 --ta "%a" --tt "%t" --tl "%g" --ty "%y" --tn "%n"

Mocht je meer interesse hebben kan ik altijd helpen met het instellen van EAC i.c.m. Lame. Het kost even tijd om het maximale eruit te halen. EAC kan ook ongecomprimeerd rippen, het is sowiso het beste programma tot zover ik weet.

EAC gebruik ik zelf ook, in de "geen compressie" mode. Zeker met de AccurateRip plugin als controle krijg je zeer goede resultaten.
En met > 5x effectieve snelheid is het nog te doen.

Ik heb nog geen test gedaan of het verschil tussen een EAC rip en bijvoorbeeld een met Audiograbber hoorbaar is.
Misschien iets voor een toekomstige shootout, als we er van overtuigd zijn dat een bestand op de computer met dusdanige kwaliteit af te spelen is op een stereo set dat dit soort verschillen er uit te halen zijn

[sphere]

Compressie an sich is een non-issue. Wat veel belangrijker is, is het verschil tussen lossless en lossy. FLAC en APE zijn prima manieren om muziek lossless te comprimeren. Dat wil zeggen dat het verschil met de geripte audiofile na compressie/decompressie cyclus 0 is. Uiteraard moet je natuurlijk stilstaan bij de manier van rippen. Daar zijn inmiddels legio sites over verschenen, maar een leuke in het Nederlands is deze: http://home.casema.nl/mogro/

Naar mijn bescheiden mening is de stelling van markvl over extra processing steps niet correct. Zodra je een wav-file op schijf hebt is de eventuele schade al berokkend (namelijk tijdens het rippen).

[Audiofiel]

Zodra je een wav-file op schijf hebt is de eventuele schade al berokkend (namelijk tijdens het rippen).

Mee eens. Net zoals bij een AIFF, AAC, Apple Lossless en MP3-bestand. Het is foutief deze te zien als een volledig identieke (auditieve) kopie van de CD.

[sandervg]

Mee eens. Net zoals bij een AIFF, AAC, Apple Lossless en MP3-bestand. Het is foutief deze te zien als een volledig identieke (auditieve) kopie van de CD.

Dat snap ik niet. Als er leesfouten zijn, zal EAC de informatie toch gewoon nóg een keer lezen?  Op deze manier krijg je toch een exacte kopie van de CD op je schijf (tenzij de CD zo beschadigd is dat het met her-lezen niet meer op te lossen is en er toch geinterpolleerd moet worden oid)

[Audiofiel]

Dat snap ik niet. Als er leesfouten zijn, zal EAC de informatie toch gewoon nóg een keer lezen?  Op deze manier krijg je toch een exacte kopie van de CD op je schijf (tenzij de CD zo beschadigd is dat het met her-lezen niet meer op te lossen is en er toch geinterpolleerd moet worden oid)

Je kunt CD-rippen niet zien als eenzelfde handeling als een computerbestand lezen. Bij dat laatste is een bit-voor-bit kopie mogelijk zonder problemen, maar daar maakt het ook niet uit in welke tijdspanne debits binnenkomen.

Bij een CD rippen ontstaat (onder andere) jitter in het geripte bestand. Overigens bevat een CD zelf ook al (meer of minder) jitter. Eenmaal vastgelegd, is de schade dus al ontstaan.

[sandervg]

Oke. Dat wist ik niet. Ik dacht dat met EAC een exacte kopie werd gemaakt (net als met data dus) van de CD en dat jitter pas ontstond bij het real-time afspelen van een CD of het versturen van de bit over de S/PDIF uitgang. Dan ben ik erg benieuwd naar de shout out die gaat plaatsvinden. Een squeezebox-achtige zal dan eigenlijk per definitie dus een stuk slechter klinken dan de oorspronkelijke CD in een goed loopwerk (één keer minder jitter dus) en zo'n CD ROM speler (van een paar euro) zal wel de nodige jitter introduceren in vergelijking met een goed loopwerk neem ik aan!

[sphere]

Je kan EAC goed africhten, en het rippen zo laten verlopen, dat EAC x keer controleert of de gelezen bitstream identiek is aan de vorige pass(es). Persoonlijk denk ik dat je hier een vrij hoge verfijning kan bereiken, die maar zeer lastig hoorbaar zal zijn in een dubbel-blinde luistertest. Waar ik mij meer zorgen over maak, is het terugbranden op CD. Het is heel moeilijk om met je lokale fikker dezelfde kwaliteit te behalen als met een matrijs.

Helaas heb ik niet de door Audiofiel genoemde nummers, maar als Dianna Kral - Live in Paris ook goed is, kan je misschien een leuk vergelijk maken met jullie test.

[Don_Paul]

Je kunt CD-rippen niet zien als eenzelfde handeling als een computerbestand lezen. Bij dat laatste is een bit-voor-bit kopie mogelijk zonder problemen, maar daar maakt het ook niet uit in welke tijdspanne debits binnenkomen.

Bij een CD rippen ontstaat (onder andere) jitter in het geripte bestand. Overigens bevat een CD zelf ook al (meer of minder) jitter. Eenmaal vastgelegd, is de schade dus al ontstaan.

Tsja, dan komen we natuurlijk weer in een discussie over jitter terecht - want de enige manier dat ik kan beredeneren is dat de 'eentjes en nulletjes' tijdens het rippen omvallen. Tijdsverschuivingen e.d. zullen niet in het opgeslagen bestand zitten - althans, als ze tijdens het rippen optreden zitten ze er alleen in indirecte vorm in, nl in de vorm van de omgevallen 1-en en 0-en.

Ik heb daar overigens laatst een aantal testen mee uitgevoerd (een aantal keren rippen van hetzelfde nummer en dan een binary compare); dit dan op hetzelfde loopwerk en met dezelfde software. Ik heb toen vastgesteld dat de rips onderling gelijk waren dus dat evt. optredende fouten iig consequent waren. Om het goed te testen zou je dit natuurlijk een groot aantal malen moeten herhalen, op verschillende platformen en met verschillende loopwerken; dat heeft vast al eens iemand gedaan denk ik dan meteen....

[Achiel]

Als je ript met EAC in de "paranoid" mode.... straffe gast (m/v) die het verschil hoort.

[markvl]

Tsja, dan komen we natuurlijk weer in een discussie over jitter terecht - want de enige manier dat ik kan beredeneren is dat de 'eentjes en nulletjes' tijdens het rippen omvallen. Tijdsverschuivingen e.d. zullen niet in het opgeslagen bestand zitten - althans, als ze tijdens het rippen optreden zitten ze er alleen in indirecte vorm in, nl in de vorm van de omgevallen 1-en en 0-en.

Dit is wat de maker van EAC er over zegt:

In secure mode, this program reads every audio sector at least twice. That is one reason why the program is so slow. But by using this technique non-identical sectors are detected. If an error occurs (read or sync error), the program keeps on reading this sector, until eight of 16 retries are identical, but at maximum one, three or five times (according to the error recovery quality) these 16 retries are read. So, in the worst case, bad sectors are read up to 82 times! But this will help the program to obtain best result by comparing all of the retries. If it is not sure that the stream is correct (at least it can be said at approx. 99.5%) the program will tell the user where the (possible) read error occurred. The program also tries to adjust the jitter artefacts that occur on the first block of a track, so that each extraction should be exactly the same. On drives found to have the "accurate stream" feature, this is guaranteed.

Ik heb daar overigens laatst een aantal testen mee uitgevoerd (een aantal keren rippen van hetzelfde nummer en dan een binary compare); dit dan op hetzelfde loopwerk en met dezelfde software. Ik heb toen vastgesteld dat de rips onderling gelijk waren dus dat evt. optredende fouten iig consequent waren. Om het goed te testen zou je dit natuurlijk een groot aantal malen moeten herhalen, op verschillende platformen en met verschillende loopwerken; dat heeft vast al eens iemand gedaan denk ik dan meteen....

Voor het vergelijken kun je de AccurateRip bij EAC gebruiken. Zie: http://www.exactaudiocopy.de/eac16.html

[Audiofiel]

Tsja, dan komen we natuurlijk weer in een discussie over jitter terecht - want de enige manier dat ik kan beredeneren is dat de 'eentjes en nulletjes' tijdens het rippen omvallen.

Jitter heeft niet te maken met omgevallen bits. Het heeft te maken met timimgsfouten. Maar ik vind het een beetje off-topic om daar weer heel uitgebreid op verder te gaan in een 'beste compressie voor CD's rippen'-topic. Er is in een ander topic al een hele discussie over ontstaan en het lijkt me niet zinvol.

Zij die geloven in een bit-voor-bit kopie is even goed als de echte CD moeten maar eens op een hele goede set (met een goed loopwerk) naar de verschillen gaan luisteren tussen hun geripte versie en de originele CD.

[sandervg]

Zij die geloven in een bit-voor-bit kopie is even goed als de echte CD moeten maar eens op een hele goede set (met een goed loopwerk) naar de verschillen gaan luisteren tussen hun geripte versie en de originele CD.

Kijk, en dat gaat dus gebeuren en de komende shootout! Ik ben benieuwd naar de resultaten 

[Don_Paul]

Jitter heeft niet te maken met omgevallen bits. Het heeft te maken met timimgsfouten.

En die zitten dus niet in een digitaal bestand op een PC. Of denk je dat de bitjes daar af en toe iets verder uit elkaar zitten? Misschien dat dat op een Mac wel zo werkt maar niet op een PC ALS jitter een rol speelt MOET het tot uiting komen in een extra of ontbrekend bitje informatie, of een 1-die-een-0 wordt, of een 0-die-een-1 wordt. Er zit nu eenmaal niets anders in die bestanden.

Zij die geloven in een bit-voor-bit kopie is even goed als de echte CD moeten maar eens op een hele goede set (met een goed loopwerk) naar de verschillen gaan luisteren tussen hun geripte versie en de originele CD.

Dat is een heel andere discussie, want dan moet je eerst opnieuw branden en daar ging het hier niet over, alleen over het rippen.

[sandervg]

Dat is een heel andere discussie, want dan moet je eerst opnieuw branden en daar ging het hier niet over, alleen over het rippen.

je kunt ze dus ook met een squeezebox afspelen --> hoef je niet opnieuw te branden. Daarom ben ik zo benieuwd naar de resultaten van de shootout van de squeezebox in vergelijking met een CD loopwerk.

Verder: het kan toch dat een bitje dat gelezen wordt door de CD ROM speler te laat op de HD komt en dus een andere code meekrijgt oid. Ik bedoel: er zal op de HD toch iets van tijdsinformatie moeten worden vastgelegd?

[markvl]

je kunt ze dus ook met een squeezebox afspelen --> hoef je niet opnieuw te branden. Daarom ben ik zo benieuwd naar de resultaten van de shootout van de squeezebox in vergelijking met een CD loopwerk.

Verder: het kan toch dat een bitje dat gelezen wordt door de CD ROM speler te laat op de HD komt en dus een andere code meekrijgt oid. Ik bedoel: er zal op de HD toch iets van tijdsinformatie moeten worden vastgelegd?

De tijdfactor is alleen van belang bij afspelen. Tot die tijd is het gewoon een serie bits.
Even een versimpeld voorbeeld:
Als je de reeks 0100011101000101000100010111101010101010101001 hebt, en je wilt hem 1-op-1 van het ene medium naar het andere copieeren, dan maakt het niet uit of je 1 ms. over het lezen doet of 100 ms. en ook niet of je 1x leest of 10x. Het enige dat telt is dat je exact het bit patroon volgt.
Als je een mp3 bestand van je PC naar je mp3-speler overzet is de bitrate van het bestand ook niet relevant.

Het begint problematisch te worden als je bron niet 100% nauwkeurig is en er leesfouten optreden; dus bijvoorbeeld als 0100 gelezen wordt als 0110 of als 0010.
In dat geval ben je afhankelijk van errorcorrectie, of je moet meerdere keren gaan lezen en hopen dat het goede patroon vaker gelezen wordt dan het verkeerde.

Pas als je de bits als onderdeel van een 'muziek'-bestand beschouwt en aan een DAC gaat doorgeven wordt timing belangrijk.
Dan moet je namelijk zo exact mogelijk de juiste hoeveelheid bits per tijdseenheid uitsturen.

[sandervg]

De tijdfactor is alleen van belang bij afspelen. Tot die tijd is het gewoon een serie bits.... Pas als je de bits als onderdeel van een 'muziek'-bestand beschouwt en aan een DAC gaat doorgeven wordt timing belangrijk.
Dan moet je namelijk zo exact mogelijk de juiste hoeveelheid bits per tijdseenheid uitsturen.

Sorry dat ik even een beetje off topic blijf.... Maar dan introduceer je bij het schrijven naar een CD-R toch ook nog geen jitter? Dan zou je toch pas bij het weer afspelen vanaf de CD-R de jitter ontstaan?  (afgezien van het feit dat lezen vanaf een CD-R misschien onnauwkeuriger gaat of dat bij het schrijven naar een CD-R misschien ander soort fouten ontstaan?)

[FrankB]

Sorry dat ik even een beetje off topic blijf.... Maar dan introduceer je bij het schrijven naar een CD-R toch ook nog geen jitter? Dan zou je toch pas bij het weer afspelen vanaf de CD-R de jitter ontstaan?  (afgezien van het feit dat lezen vanaf een CD-R misschien onnauwkeuriger gaat of dat bij het schrijven naar een CD-R misschien ander soort fouten ontstaan?)

Bij het schrijven maak je de jitter permanent. De cd bevat dan al timingsproblemen (bits die te kort of te lang na elkaar komen) die je bij het uitlezen niet kunt corrigeren. Het zal dan alleen nog maar erger worden.

[Audiofiel]

Jongens, is dat die zin en onzin over bitjes kopiëren en jitter bij rippen niet beter in een ander topic te plaatsen? De topicstarter vroeg zich het volgende af:

"wil ik eens vragen wat jullie gedachten over rippen met compressie zijn"

Deze discussie ontaard langzaamaan in een meningen-kwestie die zwaar off-topic is.


Hoewel ik mij realiseer dat de topicstarter zelf ook off-topic gaat.

[Ettepet]

Deze discussie ontaard langzaamaan in een meningen-kwestie die zwaar off-topic is.

Precies.  Het is duidelijk dat een computer met externe gadget (SB/AP/enz) in principe 'het perfecte loopwerk' is, omdat een belangrijk deel van de jitter is verdwenen.  Dure hardware die nodig is om real-time een imperfect medium als een cd op de beste manier af te lezen wordt spelend vanaf de harde schijf overbodig.  Als de gadget goed genoeg is kunnen Wadia enz. wel inpakken met hun overprijste cd-spelers.  Discussies daarover zijn bij voorbaat al zinloos.

Voor het laatst zag ik dit soort discussies vele jaren terug toen de computer nooit beter zou kunnen schaken dan een mens, gek genoeg hoor je zelfs van top-schakers daar weinig meer over.  Trek je lering zou ik zeggen.

On topic: ik begrijp de vraag van de topic-opener niet.  Wat is het probleem van lossless-compressie als een SqueezeBox of Airport het bestand uit kan pakken?  Of bedoel je dat er zo min mogelijk verstorende activiteiten in zo'n apparaatje zou moeten plaatsvinden vanwege interferentie?  Als er geen bijwerkingen optreden bij het omzetten dan is dat verder prima toch?

[Audiofiel]

Precies.  Het is duidelijk dat een computer met externe gadget (SB/AP/enz) in principe 'het perfecte loopwerk' is, omdat een belangrijk deel van de jitter is verdwenen.

Dat is dus juist niet duidelijk. Je zult eerst moeten luisteren op een goede set en vergelijken met een goed loopwerk voor je zulke conclusies kunt trekken. Wacht maar eerst de bevindingen van de shootout af.

Wat is het probleem van lossless-compressie als een SqueezeBox of Airport het bestand uit kan pakken?  Of bedoel je dat er zo min mogelijk verstorende activiteiten in zo'n apparaatje zou moeten plaatsvinden vanwege interferentie?  Als er geen bijwerkingen optreden bij het omzetten dan is dat verder prima toch?

Er kunnen verschillen ontstaan bij het decoderen van een gecomprimeerd bestand, onder meer weer in jitter.

[Ettepet]

Dat is dus juist niet duidelijk. Je zult eerst moeten luisteren op een goede set en vergelijken met een goed loopwerk voor je zulke conclusies kunt trekken. Wacht maar eerst de bevindingen van de shootout af.

Hoh, hoh, hoh, hoh!!!   Ik zeg niet dat de SqueezeBox de Wadia verslaat, alleen dat een dergelijk gadget (mits goed opgebouwd) minstens gelijkwaardig kan zijn.  Maar we raken weer off-topic..

Er kunnen verschillen ontstaan bij het decoderen van een gecomprimeerd bestand, onder meer weer in jitter.

In principe is dit klinklare onzin.  Als de hardware zorgt dat het buffer voor afspelen ten allen tijde netjes gevuld is dan is er hooguit sprake van interferentie door al dat gereken (en wisselvallige stroomverbruik) vlak naast de afspeelhardware.