Audiofiele CD ripping voor Linux & MacOSX nu met rubyripper

Started by Del member, January 19, 2007, 16:17:34

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Willen jullie een howto ?

JA
21 (61.8%)
NEE
8 (23.5%)
DONT HAVE A CLUE
5 (14.7%)

Total Members Voted: 34

Raphie

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

Audiofiel

Quote from: Raphie on January 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? ;)
Men heeft nooit gebrek aan slechte redenen om het goede na te laten, noch aan goede om het slechte te doen.

Del member

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

Del member

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.

hifiman


Del member

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.

Del member

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.

Audiotwin

Tevredenheid!!!

Del member

Quote from: Audiotwin on January 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.

Mark S

Een goed (beter) OSX alternatief voor iTunes om te rippen en converteren is Sourceforge Max

Del member

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

Hakker

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.

Del member

Quote from: Hakker on August 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 :)

Wimpie007

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? :)
CinéSas:ThemeScene H56A, Marantz SR4600, DIY - Profigold - Lapp kabels, Samsung DVD, HTPC, Wharfedale Diamond 9.1 surround,...DVD collectie
Stereo: Sony ES EV, Classé VV, Marantz CD5000, PC, Wharfedale Pacific Evolution 10,...

Del member

Quote from: Wimpie007 on August 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.

hifiman

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

bodiug

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

Del member

Quote from: Audioloog on 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
}

garmtz

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

hifiman

Quote from: guidob on 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!)

hifiman

Quote from: garmtz on 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).

Del member

#46
Quote from: garmtz on 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

hifiman

Quote from: Klinkt Beter on 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  :)

garmtz


pch

Quote from: garmtz on 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.