Audiofiele CD ripping voor Linux & MacOSX nu met rubyripper

[Del member]

Ik ben momenteel een bestaande cd ripper "abcde" (A Better CD Encoder) onder Linux aan het aanpassen zodat hij meer aan mijn noden voldoet. abcde zou je de EAC onder Linux kunnnen noemen. Hij gebruikt cdparanoia voor perfecte 1 op 1 rips.

Daarbij ben ik de abcde functionaliteit aan het uitbreiden met volgende nuttige features :

- volledig geautomatiseerd rippen :

je steekt de cd erin en hij begint, als hij klaar is eject hij, steek je de volgende cd erin begint hij gewoon opnieuw
standaard wil hij al niet starten als er geen cd in zit, dit moest beter (zoals cd2ogg)
dit is een pak sneller dan al het geclick in eac alvorens de cd start met rippen

wat hij oa standaard reeds doet : aanmaken van cue sheet, aanmaken van playlists, error logging, flac convertie, flac ogg vorbis tags (dus de cddb data komt in de metadata van de flac te staan wat nuttig is voor software die databases aanlegt van je audiofiles)

- utf8 support

de data in cddb zit in 8bits latin1 formaat wat voor een aantal problemen zorgt
linux en samba zijn nu default utf8 en windows praat ook utf8 voor file sharing via netbios

mijn utf8 support zorgt dat de filenames utf8 compliant zijn zodat ze exact matchen met die uit de playlist en foobar er overweg mee kan. in de flac files hou ik de originele latin1 data aan - kans zit er in dat dit ook utf8 gaat worden aangezien cddb protocol 6  utf8 is

Ondertussen heb ik al een berg CD's met deze bijeengehackte setup geconverteerd. Als er minstens 10 forummers zijn die dit nuttig vinden ga ik eens een howto maken.

De howto richt zich tot mensen die al iets van linux weten en bvb weten hoe ze source code patchen en basic troubleshooting.
Ik ga voorlopig debian, centos en fedora core opnemen als distributies. Onder mac OSX zou het ook werken.

Indien je nog steeds geinteresseerd bent stem dan JA op de poll.
Indien je reeds een andere ripper gebruikt en geen noodg hebt aan iets anders stem dan NEE.
Is dit allemaal chinees stem dan DONT HAVE A CLUE

Bij voldoende stemmen maak ik een Howto.

[Rody]

iTunes does it all 

[Del member]

iTunes does it all 

Fijn maar kan itunes ook flac native encoderen ipv de lossy niet audiofiele aac files ?

[Raphie]

iTunes heeft tevens geen fatsoenlijke error correctie, dus die ript gewoon door met alle vervorming/leesfouten vandien.....

[hifiman]

Ik ben wel nieuwsgierig! 

[Raphie]

Ik wil niet oneerbiedig klinken, maar je hebt een shell script gemaakt die het rip proces rondom cdparanoia automatiseert 

yeppers ub4b maakt het weer spannender dan het is

[hifiman]

yeppers ub4b maakt het weer spannender dan het is

Heb ik dat echt geschreven? 

[Raphie]

Heb ik dat echt geschreven? 

Desalniettemin, wordt deze inspanning wel gewaardeerd! 

[Del member]

yeppers ub4b maakt het weer spannender dan het is

die dingen bestaan reeds, cd2ogg en abcde (en wellicht nog 10 andere)
maar ze doen niet wat ik wil

abcde manual is echt sucky en werkt al niet default juist met flac (2 parameters zijn al niet meer up to date)
utf8 debuggen en uitzoeken ben ik een nachtje mee bezig geweest - ik wou dat foobar de playlists juist deed
foobar is kwa geluidskwaliteit wel beter dan itunes kijk naar de bevindingen van emperical audio

het automatiseren van de cd insert was 10 mins werk (weet wel iets van shell scripts)

nu ja als hier teveel mensen zagen dan steek ik er geen extra werk in, simple as that

een cd rippen is hier nu volledig automatisch
moet gewoon de cd erin duwen en als ie klaar is wordt hij uitgeworpen
muis en keyboard zijn zelfs niet meer nodig zelfs een kind kan nu cd's rippen

met EAC en itunes moet je wellicht ook nog enkele clicks doen wat gewoon dom monkey werk is als je honderden cd's wilt encoden

[hifiman]

Ub4b, ten eerste had ik je openingspost niet goed gelezen en had daarom mijn reaktie al  snel weer aangepast. Helaas had Raphie snel als hij is mijn eerste reaktie alweer ge-quote

Om een lang verhaal kort te maken, ik ben wel geinteresseerd! Sterker nog ik wilde zelf iets dergelijks gaan maken (op basis van shell scripting) omdat ik binnenkort mijn Squeezebox binnenkrijg en als deze bevalt dan ga ik het slimserver gebeuren ook op linux draaien.

Ik ben dus zeker geinteresseerd, sorry als dat anders is overgekomen!

[ThomasBelgium]

Alles wat het leven makkelijker en meer audiofiel maakt is de moeite waard!

Ik stem dus JA.

[Del member]

Om een lang verhaal kort te maken, ik ben wel geinteresseerd! Sterker nog ik wilde zelf iets dergelijks gaan maken (op basis van shell scripting) omdat ik binnenkort mijn Squeezebox binnenkrijg en als deze bevalt dan ga ik het slimserver gebeuren ook op linux draaien.

Grappig want na het lezen van de review van die nieuwe high-end squeezebox met de vu meters ben ik eraan begonnen.
Gewoon omdat ik reeds lang al m'n audio in een gestandaardiseerd high-end formaat wil met de juiste database tags.

Of ik dan nu met foobar speel, of met traktor3 DJ (dit kan mixen op 24/88.2) of met een slim devices speeltje, in alle gevallen is m'n muziek collectie dan op de correcte manier geencodeerd.

[Audiofiel]

iTunes heeft tevens geen fatsoenlijke error correctie, dus die ript gewoon door met alle vervorming/leesfouten vandien.....

Hoe kom je daar toch bij?

[Audiofiel]

Fijn maar kan itunes ook flac native encoderen ipv de lossy niet audiofiele aac files ?

Ik ben dus zelf ook niet geïnteresseerd aangezien ik Apple Lossless gebruik en dus geen flac.

[hifiman]

Hoe kom je daar toch bij?

Er is meer winst te behalen dan foutcorrectie alleen...Technieken zoals het 16x lezen van en sector en deze alleen accepteren als het resultaat minimaal 14x hetzelfde is. Of wat dacht je van de checksum over de geripte cd track vergelijken met een database van andere rippers. Dit soort technieken zitten niet in die apple ripper.

[hifiman]

leeg

[Audiofiel]

Het is je al vaker verweten dat je erg veel (losse) posts maakt, maar zo kom je wel heel erg snel aan je posts, Ronald...

Ik snap je je punt wel over 16x lezen en dergelijke, maar zie het nut er absoluut niet van in. Het grootste probleem is niet het aantal malen dat je ript of dat de uitgelezen bit-voor-bit fouten ten opzichte van het origineel... Het gaat hier immers niet om een uit te lezen computerbestand van CD-ROM, maar om de opgeslagen PCM-stream op de audio-CD. Ondanks 16x uitlezen kun je nog steeds eindigen met weliswaar vrijwel 'bitperfect' maar jitterrijk bestand.

Daarnaast geldt dat audiobestanden vanaf de computer - hoe goed ook –  voor mij slechts een slap aftreksel blijven van een originele CD, zelfs op een high end DAC (zoals ik al eens met een paar forumleden heb mogen ondervinden). Dus waarom zou ik mij dan nog zorgen maken over een 99,5 of 99,9% bitperfect bestand op mijn schijf? Voor alle duidelijkheid: ik heb al mijn 1100 CD's op de computer staan, maar ik gebruik ze slechts als achtergrondmuziek via de AirPort Express, bij eigen videomontages en als muziek bij foto(dia)-presentaties.

[Del member]

Er is meer winst te behalen dan foutcorrectie alleen...Technieken zoals het 16x lezen van en sector en deze alleen accepteren als het resultaat minimaal 14x hetzelfde is. Of wat dacht je van de checksum over de geripte cd track vergelijken met een database van andere rippers. Dit soort technieken zitten niet in die apple ripper.

Your point ?

Ik heb een hele berg CD drives en ik weet dat zowel mijn Plextor als mijn Pioneer juist rippen. Dat heb ik al op verschillende manieren getest en hoeft geen verdere uitleg.

Ik heb voor de grap eens 4 drives aangesloten en 4 rip processen tegelijk gestart (doe dat eens met je itunes), de twee hierboven welke betrouwbaar zijn en nog een goedkope cd-writer van goldstar en de NEC cd-rom uit een oude dell pc.

Met deze twee laatste schiet de foutcorrectie al in gang met recente cd's. Met de twee andere heb ik nog geen enkele cd waarbij de foutcorrectie echt nodig was omdat de loopwerkjes op zich betrouwbaar zijn.

[Del member]

Oh ja, mensen die denken dat jitter in een WAV bestand (of flac bestand) kan geraken moeten dringend 4 jaar als straf een opleiding  industrieel ingenieur electronica met optie informatica gaan studeren.

Bedoel dan de jitter zoals we die ondervinden tussen verschillende digitale interlinkjes, tussen loopwerkjes.

Jitter is asynchrone timing een WAVE bestand heeft synchrone timing (lineaire schaal) en geen notie van jitter. Enkel als we de data iet kunnen uitlezen omwille van een slecht loopwerk of te zwaar beschadigde track dan moet de foutcorrectie in gang schieten, maar das geen jitter correctie maar gewoon foutcorrectie zoals elk cd loopwerk dat doet.

ALs een airport express minder klinkt dan je duur loopwerkje is niet het flac bestand de oorzaak maar de manier waarop die crappy sp/dif interface is geimpleneteerd. Koop eens een deftige interface zoals de mod van emperical audio of een freeway en dan zullen we eens vergelijken

[Audiofiel]

Oh ja, mensen die denken dat jitter in een WAV bestand (of flac bestand) kan geraken moeten dringend 4 jaar als straf een opleiding  industrieel ingenieur electronica met optie informatica gaan studeren.

Beetje flauw, Frederique. 
Overigens heb ik HBO electrotechniek gestudeerd, zij het slechts 1 jaar

ALs een airport express minder klinkt dan je duur loopwerkje is niet het flac bestand de oorzaak maar de manier waarop die crappy sp/dif interface is geimpleneteerd. Koop eens een deftige interface zoals de mod van emperical audio of een freeway en dan zullen we eens vergelijken

Ik heb een gemodde SB gehoord op een high end DAC, dus echt niet alleen de APX. En ik geloof niet in het gebruiken van een (vuile!) pc als bron in een high end set.

Maar goed, je kunt zoveel technische zaken aanvoeren als je wilt, maar je zult me daar niet mee overtuigen. En dat hoeft toch ook niet? Muziek beluisteren is een subjectieve beleving, daarvan staan de voorbeelden vol op dit forum. Dus laten we iedereen in zijn waarde. Ik blijf lekker CD's draaien, een ander draait zijn WAV, FLAC, AAC of wat dan ook vanaf zijn computer...

[hifiman]

Beetje flauw, Frederique. 

De opmerking an sich mag dan wat flauw zijn maar hij heeft dus m.i. wel gelijk, een harddisk als muziekbron is superieur aan een (megaduur) loopwerk. Dat een pc vies is doet er niet toe zolang er bitferfect gewerkt wordt (harddisk, tcpip, enz..). Dat het eindresultaat toch doorslaat naar het loopwerk ligt aan andere zaken, met name de uiteindelijk asynchrone transfer naar de DAC.

[Audiofiel]

De opmerking an sich mag dan wat flauw zijn maar hij heeft dus m.i. wel gelijk, een harddisk als muziekbron is superieur aan een (megaduur) loopwerk.

Zolang het medium audio-CD er tussen zit, is dat natuurlijk niet waar. Het zou pas anders worden als je het originele bestand zou hebben, voordat het op CD gezet was.

Dat een pc vies is doet er niet toe zolang er bitferfect gewerkt wordt (harddisk, tcpip, enz..). Dat het eindresultaat toch doorslaat naar het loopwerk ligt aan andere zaken, met name de uiteindelijk asynchrone transfer naar de DAC.

Met vies bedoel ik dat je liever geen PC als bron wilt hebben omdat je te maken hebt met allerlei stroomvervuilers in een computer. Om nog maar te zwijgen van de enorme HF storingen.

[Del member]

De opmerking an sich mag dan wat flauw zijn maar hij heeft dus m.i. wel gelijk, een harddisk als muziekbron is superieur aan een (megaduur) loopwerk. Dat een pc vies is doet er niet toe zolang er bitferfect gewerkt wordt (harddisk, tcpip, enz..). Dat het eindresultaat toch doorslaat naar het loopwerk ligt aan andere zaken, met name de uiteindelijk asynchrone transfer naar de DAC.

Trouwens, ik rip op een Linux bak die misschien wel vuil is kwa jitter (4 netwerkkaarten, drie IDE kabels die bloot liggen tot aan de loopwerkjes), maar deze bak gebruik ik niet om af te spelen - enkel om de data op m'n netwerk te krijgen. Jitter correctie in iets als cdparanoia of EAC is iets anders als bvb SP/DIF jitter (of HDMI jitter).

Toen cd ripping nog in z'n kinderschoenen stond betekende jitter het clicken en poppen van het geluid, omdat bepaalde sectoren niet goed konden werden uitgelezen. Echte data errors dus omdat de data niet kan worden uitgelezen. Soms milliseconden aan data die verloren gaan.

Dit omdat de API interface om op een gestructureerde manier te rippen nog niet op punt stond (dus om low-level aan de data op de audio cd te geraken). Vandaar dus de historische jitter correctie. cdparanoia was toen gewoon het beste pakket wat dit goed deed. Vandaar dus ook weer de hele zooi leesstrategieen bij EAC wat gewoon erg op cdparanoia lijkt.

Jitter in de audiofiele wereld is het niet juist toekomen van de data op de maat waarop de bron clock loopt. Alhoewel de data in de juiste volgorde toekomt en binnen de timing marges (en daardoor inherent JUIST is) hebben deze subtiele variaties invloed op de DAC (zie oa de Guido Tent workshop waarom, presentatie met details op audioforum). Dit is dus in de orde van pico en nanoseconden.

Dit soort jitter heb je in een PC ook maar dit heeft niks met ripping te maken. In een wave bestand heb je enkel harde errors als data niet kan uitgelezen worden, ofwel heb je dan geen data of een interpolatie (scratch correction). De subtiele jitter in de audiofiele wereld is NIET van toepassing op een wave of flac bestand.

Als dat wave of flac bestand naar buiten moet via een interface heb je wel weer dezelfde problematiek als diegene waar alle high-end loopwerkjes en SP/DIF uitgangen last van hebben. Voor dit doel heb ik dan ook een laptop die beter klinkt dan menig PC met een vieze interne voeding. De laptop kan immers op batterij werken.

Kijk, als cdparanoia tijdens het rippen een balk met spaties geeft dan vind ie geen fouten tijdens het rippen. CD paranoia is redelijk betrouwbaar daarin. Als ie scratch correction moet doen of het loopwerkje tegensputtert bij sommige leesoperaties dan weet je het snel genoeg. Ik heb deze dedicated bak gezet omdat ik eerst vanuit VmWare wou gaan rippen.

Maar de VmWare USB interface naar de guest OS is gewoon niet stabiel genoeg als je het ding stressed. De usb driver in Linux hangt dan plots en enkel de virtuele machine rebooten helpt. Dat was dus geen oplossing. Als dit gebeurt heb je een logfile

Dus ik denk wel dat ik heel goed weet waarover ik spreek. Ik heb ooit nog cdparanoia op plextor vergeleken met de plextools en bij het rippen naar een WAVE bestand waren beide files binair identiek. Kortom cdparanioa vertrouw ik meer dan EAC met al z'n obscure instellingen. Als gevolg ripped iedereen ook andere met EAC, de logfiles op bepaale torrent sites zijn daarvan een voorbeeld.

Leuk weetje : Xiph.org  = the same team behind icecast, ogg and FLAC develops cdparanoia

[Raphie]

Hoe kom je daar toch bij?

Fatsoenlijke correctie! bij moeilijkere CD's maakt Itunes er een zooitje van....

[Audiofiel]

Fatsoenlijke correctie! bij moeilijkere CD's maakt Itunes er een zooitje van....

Tsja, ik ben erg zuinig op mijn CD's en die zijn dus vrijwel zonder krassen.

Maar ik ben bij die 1100 CD's geen eentje tegengekomen die na inlezen een zooitje gaf. Ik vraag mij dus af wat je daarmee bedoelt...