Htforum.nl

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.

iTunes does it all  ;D

Citaat van: Rody op januari 19, 2007, 16:28:44
iTunes does it all  ;D

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

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

Ik ben wel nieuwsgierig!  :)

Citaat van: Audioloog op januari 19, 2007, 16:44:35
Ik wil niet oneerbiedig klinken, maar je hebt een shell script gemaakt die het rip proces rondom cdparanoia automatiseert  ???

yeppers ;D ub4b maakt het weer spannender dan het is ;)

Citaat van: Raphie op januari 19, 2007, 16:45:56
yeppers ;D ub4b maakt het weer spannender dan het is ;)

Heb ik dat echt geschreven?  ;D

Citaat van: Audioloog op januari 19, 2007, 16:50:29
Heb ik dat echt geschreven?  ;D

Desalniettemin, wordt deze inspanning wel gewaardeerd!  8)

Citaat van: Raphie op januari 19, 2007, 16:45:56
yeppers ;D 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

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 :P

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!

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

Ik stem dus JA. >:D

Citaat van: Audioloog op januari 19, 2007, 17:06:23
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.

Citaat van: Raphie op januari 19, 2007, 16:38:55
iTunes heeft tevens geen fatsoenlijke error correctie, dus die ript gewoon door met alle vervorming/leesfouten vandien.....

Hoe kom je daar toch bij? ::)

Citaat van: ub4b op januari 19, 2007, 16:37:01
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. ;)

Citaat van: Audiofiel op januari 19, 2007, 18:02:58
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.

leeg

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... :P

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. ;)

Citaat van: Audioloog op januari 19, 2007, 19:54:15
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.

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 :)

Citaat van: ub4b op januari 19, 2007, 21:02:04
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

CiteerALs 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... ;)

Citaat van: Audiofiel op januari 19, 2007, 21:20:03
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.

Citaat van: Audioloog op januari 19, 2007, 21:41:05
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. ;)

CiteerDat 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. ;)

Citaat van: Audioloog op januari 19, 2007, 21:41:05
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 :)

Citaat van: Audiofiel op januari 19, 2007, 18:02:58
Hoe kom je daar toch bij? ::)

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

Citaat van: Raphie op januari 19, 2007, 22:58:19
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... ;)

klicks & plops op bepaalde tracks, CDR's die niet goed worden gelezen etc. met WMP totaal geen last.

Citaat van: Raphie op januari 19, 2007, 23:11:45
klicks & plops op bepaalde tracks, CDR's die niet goed worden gelezen etc. met WMP totaal geen last.

Apart. Geen last van gehad. Klinkt als een te snel draaiende CD-drive tijdens het inlezen of zoiets.


Waarom zou je overigens een CD-R willen inlezen? Die CD-R was toch voor eigen gebruik gebrand? Dus dan heb je de originele CD ook nog om in te lezen, toch? ;)

Paranoia als ik ben ga ik nog wat wave files tussen de vier verschillende drives vergelijken.
Eens wat verschillende CD's nemen kwa type (een gold, een gewone, een gold-cdr, een oude tdk cd-r,...) en die dan op de verschillende drives rippen en dan een EAC wave compare.

Ondertussen ook al wat vreemde dingen over cdparanoia gelezen. Maar er is zelfs een freak die cdparanoia gebruikt met een ruby frontend en het test & compare algoritme van EAC om bvb met data caching in de drive om te gaan.

Als het met maar twee drives tegelijk moet so be it ...

Ik vertrouw die Goldstar voor geen haar. Een korte EAC wave compare leert dat er een verschil zit in de eerste 2 seconden wat op pre-gap (mis)detectie lijkt. Straks weet ik meer. Audiofiel als ik ben moet het gewoon perfect zijn en liefst geautomatiseerd :)

Ben er eindelijk uit met de hele offset zever.

Ben even beginnen vergelijken tussen m'n twee betrouwbare drives :

- PX-W4012A Rev: 1.06
- Pioneer DVD-106S 012

Met beide drie tracks geript van een CD die ik dubbel heb. De Pioneer file vertoont in het begin 4 repeated samples volgens de Wave Compare tool in EAC, wat basically wil zeggen dat hij 4 samples te vroeg begint tov de Plextor. Analyse met een wave editor lijkt dat het geen zero padded bytes zijn maar gewoon wat onhoorbare noise.

cdparanoia -O +4 op de pioneer probleem opgelost - beide files matchen identiek. Mooi want dit zijn twee totaal verschillende loopwerkjes.

Maar ergens klopt de redenering nog niet helemaal. De Pioneer heeft normaal een offset correctie van +102, de plextor van +98.

De plextor leest dus maar 98 samples te vroeg, de Pioneer 102 samples te vroeg. +4 op de Pioneer zorgt dat ze beide gelijklopen (98 samples te vroeg) maar nog niet volgens het begin van waar de data staat. Het verschil wat ik proefondervindelijk kan waarnemen klopt dus wel met de offset database die je bvb hier kan vinden :

http://users.pandora.be/satcp/eacoffsets01.htm

Kortom een oplossing maken die perfect ript en dan nog batched is geen sinecure en vergt toch wel wat inspanning. Als ultieme test ga ik de Linux rips met de juiste offsets steekproefgewijs vergelijken met wat EAC ervan bakt.

Keep up the good work  :D

Na nog wat verder offset gepruts heb ik leuke resultaten :

- met origineel gekochte CD's zowel Plextor als Goldstar identieke rips, zelfs de flacs die er uit komen zijn identiek :)
- met bepaalde CDR's gaat de Goldstar de mist in en schiet de error correctie van cdparania in gang

Dit laatste geeft op bepaald moment SCSI errors (alles in Linux loopt over een scsi layer) en dan heb je harde errors in de stream : "e" in de cdparanoia status.

De goldstar is minder goed dan de plextor maar doet GEEN CACHING wat wil zeggen dat secure rip wel mogelijk is. Net zoals EAC leest cdparanoia de sectoren meermaals en met caching krijg je gewoon het eerste leesresultaat twee keer en dan denkt je ripper dat er geen fouten zijn. EAC heeft iets tegen caching gevonden cdparanoia nog niet maar cdparanoia IV wordt ook niet echt aan verdergewerkt.

Omdat ik secure wil werken heb ik een strategie bedacht die 2x meer tijd kost (maar even veel tijd als met 1 drive rippen) maar wel automated is :

- elke cd wordt eerst geript in de goldstar, voor bepaalde probleem cdr merken in de Pioneer - beide loopwerkjes duwen hun data in bvb /data/gold
- en daarna in de plextor -> /data/plex

maar dus wel altijd 2 cd's die tegelijk bezig zijn. Na een batch van pak 25cd's draai ik rsync -avrnrIc /data/plex/ /data/gold (vergelijk beide dirs enkel op fileinhoud met checksums en ignore de timestamps en filegroottes) en weet ik direct welke rips niet 100% zijn. Makkelijker dan de EAC logfile lezen :) Die probleem cd's hou ik apart en dan manueel vergelijken met bvb EAC wave compare. Meestal zal 1 drive er wel juist op zitten.

Als twee loopwerkjes het 100% eens mee zijn dat de rips identiek zijn dan is dit voor mij goed genoeg :)

Vind dit een betere assumptie dan dat 2x in eenzelfde drive rippen ook 2x dezelfde fout oplevert en de ripper denkt dat er geen fout is.

Een sexy abcde feature zou zijn dat hij zelf vraagt : steek nu cd in tweede loopwerkje en dat hij alles zelf doet.
Maar rsync is ook plain simple en 200% betrouwbaar - heb er al gehele servers mee overgezet van een simpele mailserver tot een zware oracle.

Deze thread gaat voorlopig even de ijskast in omdat ik nog een extra loopwerkje zoek wat betrouwbaar is.

Ik wil op een geautomatiseerde manier elke cd twee keer kunnen gaan uitlezen en m'n goldstar is niet betrouwbaar genoeg om dit op grote schaal te doen, 1 op 3 cd's geeft verschillend checksum tov m'n plextor wat een te grote moeite is om de probleem cd's manueel met EAC te doen.

Dus ben nog aan 't zoeken naar een tweede loopwerk wat betrouwbaar is.

En binnen 5 jaar alles opnieuw  ;)
http://www.telegraaf.nl/i-mail/57652971/CD_na_vijf_jaar_kapot.html

Citaat van: Audiotwin op januari 27, 2007, 16:31:38
En binnen 5 jaar alles opnieuw  ;)
http://www.telegraaf.nl/i-mail/57652971/CD_na_vijf_jaar_kapot.html

Ik heb cd's van meer dan 6 jaar oud die nog spelen. Zal binnenkort ervaren hoeveel error correction er nodig is.
M'n plextor premium doet ook C1/C2 en jitter testen zal deze es loslaten op die oude cd's.

Tegenwoordig brand ik enkel nog op gold cd's deze gaan veel langer mee.

Een goed (beter) OSX alternatief voor iTunes om te rippen en converteren is Sourceforge Max (http://www.versiontracker.com/dyn/moreinfo/macosx/28353)

Ik heb net rubyripper op een oude AMD-K6-400 met 256MB ram aan de praat gekregen en een oude PLEXTOR CD-R PX-W4012A. Zal eens wat rips maken en ze daarna overdoen met de Plextor Premium. Met abcde en cdparanoia kreeg ik nooit exact dezelfde rips tss beide drives eens kijken hoe clever de foutcorrectie in rubyripper is :) Och ja de offset correctie heb ik wel juist voor mekaar tussen beide drivers dat is het dus niet.

De nodig libraries zoals libglade2-ruby zijn lastig te vinden op de laatste CentOS (RedHat enterprise clone) dus ze maar snel op een Debian Sarge in gang geduwd. Dus op een ubuntu ook bijna out of the box wellicht. In 4G's lab een berg linux varianten gewoon door mekaar :)

Ik heb een aantal cd's met beruchte 'kapotte' laatste tracks waaronder een aantal cafe del mars. Rubyripper ript elke track 2 keer. Het veronderstelt dat de onderliggende ripper een black box is die niet te vertrouwen is. Het veronderstelt dat errors random fouten moeten geven. Na 2x rippen gaat het beide file vergelijken en gelijke blokken van 1000 bytes in een nieuwe file herbergen. Het weet dan welke blokken nog ontbreekt, en gaat dan weer opnieuw gaan rippen tot er meer gelijke blokken opduiken.

Op de laatste track van "cafe solo" CD1 is hij nu al 34 keer aan 't vergelijken tot er geen resterende blokken meer zijn die verschillend zijn...

Voordeel van deze ripper :

-vlot te automatiseren, scriptable, kan unattended rippen (wellicht mits wat kleine aanpassingen)
-flac support, playlists en cddb
-systeem footprint waarop het draait is een lachertje

Nadeel van deze ripper :

bij foute tracks wordt de hele track opnieuw 2x gelezen:

-rw-r--r-- 1 root root 64908188 2007-08-21 02:02 track14_1.wav
-rw-r--r-- 1 root root 45121580 2007-08-21 02:04 track14_37.wav

gelukkig diffed hij niet met een constante eerste file, anders zou een fout in de eerste file dus nooit opgelost kunnen geraken.

Ik vind hun logica achter de methode goed alleen kan de optimalisatie nog wel beter.

Er wordt beweerd dat identieke fouten in 2 rips niet ontdekt kunnen worden. Er is daarom kritiek op EAC dat Secure Mode eigenlijk nooit secure kan zijn. Als ik met twee verschillende drives laat rubyrippen dan zal snel zichtbaar worden of dit soort errors vaak voorkomt wat geen van beide rippers authentiek kan oplossen.

Kortom rubyripper I like alleen moet er nog wat getest worden alvorens ik heel m'n cd collectie ermee doe.

Hehe ... progress ... nog 1000 bytes to go :

1 chunk(s) didn't match 2 times.
Starting to rip track 14, trial 41#

Dit is een leuke ripper voor mensen met veel tijd  >:D Backgroundtijd haha

wil best wel eens op een ubuntu bak proberen als ik door heb hoe ik het kan installen :) wordt langzaam aan beter in linux maar is nog een lange weg te gaan denk ik :)
Kan dan ook nog een vloot drives erover gooien. oa NEC DVD drives, Lite-ON en nog een paar.

Citaat van: Hakker op augustus 21, 2007, 22:13:58
wil best wel eens op een ubuntu bak proberen als ik door heb hoe ik het kan installen :) wordt langzaam aan beter in linux maar is nog een lange weg te gaan denk ik :)
Kan dan ook nog een vloot drives erover gooien. oa NEC DVD drives, Lite-ON en nog een paar.

op een debian sarge was't kinderspel :

apt-get install cd-discid libglade2-ruby bzip2 make cdparanoia flac

en dan deze file :
http://rubyripper.googlecode.com/files/rubyripper-0.4.2.tar.bz2
afhalen, uitpakken en  rubyripper_cli.rb opstarten

Effe een 200G schijf assigned om al m'n CD's op te backup'en :)

Was je op termijn nog van plan een kleine how-to bij elkaar te schrijven, of wacht ik beter nog even af tot je huidige experimenten afgerond zijn? :)

Citaat van: Wimpie007 op augustus 28, 2007, 17:35:07
Was je op termijn nog van plan een kleine how-to bij elkaar te schrijven, of wacht ik beter nog even af tot je huidige experimenten afgerond zijn? :)

Ik heb nu 50-tal cd's geript waarvan 2 niet herstelbaar waren (rubyripper bleef een hele dag/nacht proberen). Dit soort cases is natuurlijk niet aanvaardbaar. Ik ga er een limiet in steken. En dan de flac encoding die nog breekt.

Ik ben zojuist ook geswitched van EAC naar Rubyripper.
Zit alleen effe te denken hoe jij dat automatisch detecteren van een cd hebt gedaan  ???

Cool, ik kon rubyripper nog niet. EAC via wine werkt ook prima. Maar ga hier eens mee stoeien.

Citaat van: Audioloog op november 23, 2007, 14:50:54
Ik ben zojuist ook geswitched van EAC naar Rubyripper.
Zit alleen effe te denken hoe jij dat automatisch detecteren van een cd hebt gedaan  ???

Een wait_cd() functie in je shell scriptje steken :

CDDISCID=cd-discid

wait_cd() {
CDDISCIDRETRY=0
while true
do
   TRACKINFO=$($CDDISCID $CDROM 2>/dev/null)
   # Make sure there's a CD in there by checking cd-discid's return code
   if [ "$?" = "1" ]; then
        if [ "$CDDISCIDRETRY" != "1" ]; then
            echo "error: put CD in drive or press crtrl-c" >&2
        fi
        CDDISCIDRETRY=1
        sleep 1
    else
        break
    fi
done
}

Ik ben benieuwd of er ook niet een betere ripper is voor Windows, evt. die ook gebruik maakt van cdparanoia.

Citaat van: guidob op november 23, 2007, 15:03:19
Cool, ik kon rubyripper nog niet. EAC via wine werkt ook prima. Maar ga hier eens mee stoeien.

Ik wilde persee een automatische oplossing, voorlopig even opgelost middels lirc (dus druk op de record toets van mijn afstandsbediening  ;D ). Maar de oplossing van Klinkt beter klinkt mij beter in de oren  :D (waarvoor dank!)

Citaat van: garmtz op november 23, 2007, 15:24:53
Ik ben benieuwd of er ook niet een betere ripper is voor Windows, evt. die ook gebruik maakt van cdparanoia.

Waarom eigenlijk Garmt? Theoretisch heeft EAC namelijk zelfs een streepje voor op cdparanoia, maar dankzij rubyripper is dit nadeel weggenomen  (namelijk door cdparanoia altijd 2x per track te runnen en dan te vergelijken).

Citaat van: garmtz op november 23, 2007, 15:24:53
Ik ben benieuwd of er ook niet een betere ripper is voor Windows, evt. die ook gebruik maakt van cdparanoia.

EAC is goed genoeg, alleen als je 600cd's wilt rippen is het veel te traag
een cd-ripper moet in batch kunnen rippen, het enige wat een user moet doen is het schijfje wisselen, al de rest moet de ripper slim genoeg zijn (met een config die het toelaat) om het zelf uit te vissen

en: schijfjes waar rubyripper het echt lastig mee heeft (stukje disk kapot, dus bij elke read blijft het random data, dus je loopt tegen de herlees limiet aan, bij mij 250 keer) daar loopt EAC dus ook gewoon op vast (hele nacht op 1 track is dan niet ongewoon - en blijft maar proberen)

dus geen van beide kan wonderen verrrichten als het schijfje echt kapot is  O0

Citaat van: Klinkt Beter op november 23, 2007, 15:14:41
Een wait_cd() functie in je shell scriptje steken :

CDDISCID=cd-discid

wait_cd() {
CDDISCIDRETRY=0
while true
do
   TRACKINFO=$($CDDISCID $CDROM 2>/dev/null)
   # Make sure there's a CD in there by checking cd-discid's return code
   if [ "$?" = "1" ]; then
        if [ "$CDDISCIDRETRY" != "1" ]; then
            echo "error: put CD in drive or press crtrl-c" >&2
        fi
        CDDISCIDRETRY=1
        sleep 1
    else
        break
    fi
done
}

Die echo is niet zo zinvol voor een automated oplossing en die 1 seconde sleep is wat kort om dag en nacht te pollen, maar het idee vind ik erg goed en ik ga het zeker toepassen  :)

O.k. Dank je Frederic voor het antwoord.

Citaat van: garmtz op november 23, 2007, 15:24:53
Ik ben benieuwd of er ook niet een betere ripper is voor Windows, evt. die ook gebruik maakt van cdparanoia.

Ja hoor, dat is er : Ripstation Micro!  ;D
Gebruik ik voor mijn Sonos en is eigenlijk hetzelfde als Ripfactory.

Gr. Paul.

Het is alleen jammer dat Ripstation Micro er alleen is voor Windows en niet voor Mac OS-X: ik heb sinds een aantal weken nl. een Apple, vandaar dat ik op dit topic kwam....
Is me alleen nog niet helemaal duidelijk na het topic doorgelezen te hebben of er al een kant en klaar programma nu is voor de Apple.

Gr. Paul.

P.S. Ik ben het totaal oneens (maar goed, dat is mijn mening) met Audiofiel over zijn opmerking dat muziek op cd altijd beter klinkt (per definitie) dan muziek op een HDD: ten 1e staat al mijn muziek niet op een computer maar op een WD Netcenter netwerk HDD, groot verschil lijkt mij. Daarnaast: heb jij de nieuwe Sooloos al eens beluisterd? Moet je eens doen!  ;D