Rippen mit OSX, "max Problem entdeckt" ...

[delorentzi]

Hallo,

eine Auskopplung aus dem Thread Rippen & Streamen am Mac/OSX - so mache ich es

Ausgangssituation war die folgende:

ich hatte mir max als ripping tool ausgesucht, zahlreiche Alben gerippt und dann war mir bei einem bestimmten Titel ein Knistergeräusch aufgefallen - reproduzierbar ... immer wenn ich mit max gerippt habe. Da kam es mir gelegen, dass mir XLD als Ripp Tool unter OSX empfohlen wurde.

Pah

und bei mir erst - hört, oder lest selbst meine Worte:

Life Stories 9 in das externe Laufwerk.
Mit max wieder den ersten Titel gerippt und als FLAC ablegen lassen: Four Wild Horses (David Munyon).
Mit tag die Metadaten angepasst: Titel als test-max.flac abgelegt.
Mit xld den ersten Titel gerippt und als FLAC ablegen lassen: Four Wild Horses (David Munyon).
Mit tag die Metadaten angepasst: Titel als test-xld.flac abgelegt.

auf die NAS geschoben, iphone in die Hand ... G-Sonos ... aber was lese ich Euch Schritt für Schritt vor:

test-max.flac wieder an derselben Stelle die Störgeräusche.

test-xld.flac ... ohne Fehler.

... naja, die Konsequenz daraus ... in den Mülleimer mit max und allen gerippten Alben.
Neu rippen mit XLD ...

Grüße,
Thomas

[Unicos]

Hi,

gibt es keine Software unter Mac OSX, die eine Checksumme erstellt und diese abgleicht, so wie bei DBPoweramp oder EAC moeglich?

Nichts anderes wuerde mir ins Haus kommen, wenn ich den Anspruch wie Du an Deine Aufnahmen haette.

Gruessle

Thomas

[delorentzi]

Hallo Thomas,

was soll ich sagen? Ich "arbeite" daran.

in XLD kann man sich (war wohl schon per default eingeschaltet) ein logfile erzeugen lassen:

Code: Alles auswählen

X Lossless Decoder version 20111211 (138.0)

XLD extraction logfile from 2011-12-14 10:00:20 +0000

Various Artists / Zigeunerweisen

Used drive : ATAPI iHAS624   B (revision GL29)

Ripper mode             : XLD Secure Ripper
Disable audio cache     : OK for the drive with a cache less than 1375KiB
Make use of C2 pointers : NO
Read offset correction  : 6
Max retry count         : 20
Gap status              : Not analyzed

TOC of the extracted CD
     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  | 00:00:00 | 08:16:43 |         0    |    37242   
        2  | 08:16:43 | 08:57:62 |     37243    |    77579   
        3  | 17:14:30 | 04:41:62 |     77580    |    98716   
        4  | 21:56:17 | 02:35:05 |     98717    |   110346   
        5  | 24:31:22 | 04:28:20 |    110347    |   130466   
        6  | 28:59:42 | 09:09:67 |    130467    |   171708   
        7  | 38:09:34 | 10:12:01 |    171709    |   217609   
        8  | 48:21:35 | 03:12:54 |    217610    |   232063   
        9  | 51:34:14 | 05:41:24 |    232064    |   257662   
       10  | 57:15:38 | 04:07:02 |    257663    |   276189   
       11  | 61:22:40 | 12:48:58 |    276190    |   333847   

AccurateRip Summary
    Track 01 : OK (AR2, confidence 2)
    Track 02 : OK (AR2, confidence 2)
    Track 03 : OK (AR2, confidence 2)
    Track 04 : OK (AR2, confidence 2)
    Track 05 : OK (AR2, confidence 2)
    Track 06 : OK (AR2, confidence 2)
    Track 07 : OK (AR2, confidence 2)
    Track 08 : OK (AR2, confidence 2)
    Track 09 : OK (AR2, confidence 2)
    Track 10 : OK (AR2, confidence 2)
    Track 11 : OK (AR2, confidence 2)
        ->All tracks accurately ripped.

All Tracks
    Statistics
        Read error                           : 0
        Jitter error (maybe fixed)           : 0
        Retry sector count                   : 0
        Damaged sector count                 : 0

Track 01
    Filename : /Users/****/Downloads/audio files/Zigeunerweisen/Zauber der Violine/01 Pablo de Sarasate - Ziegeunerweisen, op.20.flac
    Pre-gap length : 00:02:00

    CRC32 hash             : B132F7CA
    CRC32 hash (skip zero) : 1E6C0BFE
    AccurateRip signature  : AA2A69F4
        ->Accurately ripped! (AR2, confidence 2)
    Statistics
        Read error                           : 0
        Jitter error (maybe fixed)           : 0
        Retry sector count                   : 0
        Damaged sector count                 : 0

Track 02 .... 

Im Wesentlichen fällt mir auf das XLD mit accuraterip arbeitet, max hingegen mit cdparanoia. Hoffe ich habe das jetzt richtig formuliert. In max kann man zwar Alternativen zu cdparanoia auswählen, darunter ist aber accuraterip nicht vorhanden. Ich habe bei max "prüfe auf c2 Fehler" und "nutze SHA-256 für Sektorvergleich" sowie die "Fehlerkorrektur" eingeschaltet. In XLD kann man übrigens anstelle von accuraterip auch cdparanoid auswählen. Diese Art der Gegenprobe halte ich im Moment aber nicht für interessant. Im Moment vertrete ich eher den Standpunkt das Ergebnis von XLD ist für mich brauchbar, das Ergebnis von max nicht.

Die XLD Option "PreGap usw. nicht einlesen" nutze ich übrigens, da es sonst bei einigen CDs zu unglaubliche langen Prüfvorläufen kommt. Bei einer CD habe ich nach über einer halben Stunde "PreGap" prüfen die Nase voll gehabt und nutze das seither nicht mehr.

Achso, noch was. In der Accurate Summary kam es auch schon mal zu einem anderen Ergebnis, hinter dem Track stand OK, in Klammern ein ander Kommentar als oben) unter der Aufstellung aber der beruhigende Satz ""All tracks accurately ripped.

Grüße,
Thomas

[delorentzi]

Hallo,

habe mir XLD noch ein bsichen näher angeschaut.
C2 Fehler Korrektur eingeschaltet
die Offset correcktion steht auf 6 (auto mode)
stammt aus der accurate db, dort hätte ich auch nachgeschaut: http://www.accuraterip.com/driveoffsets.htm
... dort findet sich für mein LiteOn auch der Wert 6.

hier ein weiteres Logfile. Ich denke damit der jetzigen Konfiguration kann man gut leben:

Code: Alles auswählen

X Lossless Decoder version 20111211 (138.0)

XLD extraction logfile from 2011-12-14 12:18:41 +0000

Chuck Loeb & Andy LaVerne / Magic Fingers

Used drive : ATAPI iHAS624   B (revision GL29)

Ripper mode             : XLD Secure Ripper
Disable audio cache     : OK for the drive with a cache less than 1375KiB
Make use of C2 pointers : YES
Read offset correction  : 6
Max retry count         : 20
Gap status              : Not analyzed

TOC of the extracted CD
     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  | 00:00:00 | 04:57:15 |         0    |    22289   
        2  | 04:57:15 | 05:00:27 |     22290    |    44816   
        3  | 09:57:42 | 04:43:65 |     44817    |    66106   
        4  | 14:41:32 | 05:01:33 |     66107    |    88714   
        5  | 19:42:65 | 04:50:05 |     88715    |   110469   
        6  | 24:32:70 | 04:35:72 |    110470    |   131166   
        7  | 29:08:67 | 05:05:10 |    131167    |   154051   
        8  | 34:14:02 | 04:37:53 |    154052    |   174879   
        9  | 38:51:55 | 04:41:10 |    174880    |   195964   
       10  | 43:32:65 | 07:07:17 |    195965    |   228006   
       11  | 50:40:07 | 03:39:18 |    228007    |   244449   

List of alternate offset correction values
        #  | Absolute | Relative | Confidence 
    ------------------------------------------
        1  |    557   |    551   |     15     

AccurateRip Summary
    Track 01 : OK (confidence 8)
    Track 02 : OK (confidence 8)
    Track 03 : OK (confidence 8)
    Track 04 : OK (confidence 8)
    Track 05 : OK (confidence 8)
    Track 06 : OK (confidence 8)
    Track 07 : OK (confidence 8)
    Track 08 : OK (confidence 8)
    Track 09 : OK (confidence 8)
    Track 10 : OK (confidence 8)
    Track 11 : OK (confidence 7)
        ->All tracks accurately ripped.

All Tracks
    Statistics
        Read error                           : 0
        Jitter error (maybe fixed)           : 0
        Retry sector count                   : 0
        Damaged sector count                 : 0

Track 01
    Filename : /Users/thomaswipperfurth/Downloads/audio files/Chuck Loeb & Andy LaVerne/Magic Fingers/01 Chuck Loeb & Andy LaVerne - Book & Beads.flac
    Pre-gap length : 00:02:00

    CRC32 hash             : 67D20273
    CRC32 hash (skip zero) : 9450DEBC
    AccurateRip signature  : 218F487B
        ->Accurately ripped! (confidence 8)
    Statistics
        Read error                           : 0
        Jitter error (maybe fixed)           : 0
        Retry sector count                   : 0
        Damaged sector count                 : 0

Track 02 ...

Für einen kleinen Vergleich werde ich mal einen Ordner anlegen und zwei Stücke, die mit max und xld gerippt wurden vergleichen. Aber mal eins, wo ich keine Knisterstücke gehört habe. Vielleicht hört man ja einen Klangunterschied. Mit dem Luxus des streamens kann man ja wirklich schnell die Tracks wechseln, wenn man es sich in einem separaten Ordner vorbereitet hat.

Grüße,
Thomas

[delorentzi]

Hier ein drittes und letzes Mal, dass ich ins logfile schaue, ich denke XLD macht seine Sache gut und ich habe jetzt keine Bauchschmerzen mehr:

Code: Alles auswählen

X Lossless Decoder version 20111211 (138.0)

XLD extraction logfile from 2011-12-14 13:01:27 +0000

Yes / 90125 [Audio Fidelity 24K Gold HDCD AFZ 063]

Used drive : ATAPI iHAS624   B (revision GL29)

Ripper mode             : XLD Secure Ripper
Disable audio cache     : OK for the drive with a cache less than 1375KiB
Make use of C2 pointers : YES
Read offset correction  : 6
Max retry count         : 20
Gap status              : Not analyzed

TOC of the extracted CD
     Track |   Start  |  Length  | Start sector | End sector 
    ---------------------------------------------------------
        1  | 00:00:00 | 04:30:27 |         0    |    20276   
        2  | 04:30:27 | 05:17:56 |     20277    |    44107   
        3  | 09:48:08 | 05:29:45 |     44108    |    68827   
        4  | 15:17:53 | 06:23:59 |     68828    |    97611   
        5  | 21:41:37 | 02:07:63 |     97612    |   107199   
        6  | 23:49:25 | 04:13:33 |    107200    |   126207   
        7  | 28:02:58 | 04:17:47 |    126208    |   145529   
        8  | 32:20:30 | 04:52:45 |    145530    |   167474   
        9  | 37:13:00 | 07:40:43 |    167475    |   202017   

List of alternate offset correction values
        #  | Absolute | Relative | Confidence 
    ------------------------------------------
        1  |     12   |      6   |      2     

AccurateRip Summary
    Track 01 : OK (AR2, confidence 11)
    Track 02 : OK (AR2, confidence 11)
    Track 03 : OK (AR2, confidence 11)
    Track 04 : OK (AR2, confidence 11)
    Track 05 : OK (AR2, confidence 11)
    Track 06 : OK (AR2, confidence 11)
    Track 07 : OK (AR2, confidence 11)
    Track 08 : OK (AR2, confidence 11)
    Track 09 : OK (AR2, confidence 11)
        ->All tracks accurately ripped.

All Tracks
    Statistics
        Read error                           : 0
        Jitter error (maybe fixed)           : 0
        Retry sector count                   : 0
        Damaged sector count                 : 0

Track 01...

Lieben Gruß,
Thomas

[cantusfirmus]

Hallo Thomas,

freut mich, daß mein XLD Tipp Dir etwas gebracht hat. Die Konfiguration ist - ähnlich wie bei EAC - nicht auf den ersten Blick in allen Tiefen nachvollziehbar, zumindest für mich war das so. Ich wurschtle noch immer daran herum.

Was erwartest du Dir von der C2 Korrektur (ist das der Haken bei: "Benutze C2 Modus" unter CD Rip Einstellungen?) Ich habe da ein bisschen weiter unten übrigens bei "Maximalen Wiederholungen" 200 eingetragen, der soll sich mal plagen

einen schönen Abend wünscht Horst

[Gisorg]

Neu rippen mit XLD ...

Hallo Thomas,

danke für den Tipp mit XLD!

Bisher hatte ich mit iTunes direkt die CD ausgelesen mit rasanter CD-Geschwindigkeit. Eine Laufwerksgeschwindigkeitsreduzierung für MacOs habe ich recherchiert, aber nicht gefunden. Das es ein solch klasse Tool gibt, wusste ich noch nicht.

Jetzt bin ich dabei meine CD-Sammlung nochmals als ALAC und jetzt auch dual als FLAC zu rippen. Dabei fällt mir auf, dass a) die ALAC von XLD größer ist als die mittels iTunes und b) FLAC von XLD um meist 1-2 MB nochmals größer ist als die ALAC von XLD. Die CD-Coverbilde sind nicht im File enthalten und FLAC ist Level 0 eingestellt, also unkomprimiert genauso wie ALAC. Weiss jemand hierzu eine Erklärung?

Gruß
Daniel

[uli.brueggemann]

Dabei fällt mir auf, dass a) die ALAC von XLD größer ist als die mittels iTunes und b) FLAC von XLD um meist 1-2 MB nochmals größer ist als die ALAC von XLD. Die CD-Coverbilde sind nicht im File enthalten und FLAC ist Level 0 eingestellt, also unkomprimiert genauso wie ALAC. Weiss jemand hierzu eine Erklärung?

Daniel,

kannst Du zwei kleine Tracks hierzu zur Verfügung stellen? Dann könnte ich mal reinschauen in die Dateien und vergleichen.

Grüsse
Uli

[Gisorg]

Hallo Uli,
ich habe dir soeben eine PN zugeschickt mit dem Link zu den drei Audiofiles.
Jetzt bin ich gespannt was du rausfinden kannst.

Gruß
Daniel

[uli.brueggemann]

Hallo Daniel,

ich hab mir nun mal die Dateien angeschaut. Hierzu habe ich alle Dateien nach WAV umgewandelt, also in das entpackte Wiedergabeformat.

Die 3 Dateien sind:
A. Apple Lossless via iTunes gerippt.m4a
B. Apple Lossless via XLD gerippt.m4a
C. FLAC via XLD gerippt.flac

Ganz grob: Beim Vergleich ist zu unterscheiden zwischen DATA und LIST. DATA enthält die Musikinformation, LIST enthält Zusatzinformationen, z.B. Tags etc.

Feststellungen:
- Die Dateien sind trotz Einstellung 0 komprimiert. Nach dem Entpacken wächst der Dateiumfang bei C z.B. von 2980 kB auf 9422 kB.
- B und C weisen einen bitgenau identischen Dateninhalt auf, unterscheiden sich bzgl. der LIST-Information. Beide Dateien enthalten kein Cover.
- A wird beim Entpacken 9592 kB gross. Es ist in der LIST-Information ein Coverbild enthalten, daher die Unterschiedliche Größe. Es sind bei DATA dieselbe Anzahl an Samples enthalten. ABER: A hat bei den ersten 696 Samples (stereo) eine andere Information. Dann hat A genau dieselbe Information wie B und C, hört aber logischerweise um die 696 Samples früher auf, da gleiche Länge.

Weshalb die Datenverschiebung vorliegt kann ich nur vermuten. Es gibt bei EAC eine Erklärung, dass es notwendig ist, beim Auslesen der CD einen ordnungsgemäßen Offset zu verwenden. Den man mit EAC und einem gegebenen Laufwerk auch ermitteln kann. Ich habe insofern auch schon unterschiedlich gerippte Tracks gesehen, die jeweils eine unterschiedliche Anzahl an Samples mit dem Wert 0 vor Beginn der Musik enthalten haben. Spannend ist nun, dass bei der Datei A die 6969 Samples nicht Null sind sondern eine Information ähnlich den nachfolgenden Samples aufweisen. Ergo sieht es für mich vergleichbar so aus, als wären die Samples mit einem Editor ausgeschnitten worden, bei A aber eben um die 696 Sample zu früh.

Der Datenvergleich zeigt, dass die Musik bei den drei Dateien gleich klingen müsste, da die PCM-Daten identisch sind (bis auf besagte Verschiebung).

Grüsse
Uli

[B. Albert]

Tach allerseits,

es könnte auf Grund dieses Threads der Eindruck entstehen, dass Max ungeeignet sei, CDs ordentlich zu rippen.

Nun, es kommt natürlich immer darauf an, welche Ansprüche man an das Ergebnis stellt. Ich persönlich bin da nicht ganz so pingelig, weil ich zugegebenermaßen meine Zeit nicht so gerne vor dem Computer verbringen, sondern lieber vor den Lautsprechern .

Deshalb benutze ich neben XLD auch Max (in Kombination mit dem kleinen Skript "Get iTunes Metadata" und iTunes als Quelle der Metadaten). Die Rip-Programme laufen beide im Multiformat-Modus, so dass ich gleichzeitig mp3 und flac Dateien bekomme, erstere für meine iPods, letztere zum Streamen über den Server auf die Anlage.

Ich habe in den vergangenen Jahren sicherlich mehrere hundert CDs mit Max gerippt und noch nie eine fehlerhafte Musikdatei bekommen; zumindest sind mir noch nie irgendwelche Fehler aufgefallen und ich kann sagen, dass ich bei meiner bevorzugten Musik - vornehmlich klassische Musik - schon recht genau hinhöre.

Ich möchte damit die Beobachtung von Thomas keineswegs in Frage stellen. Anscheinend hat er da leider andere Erfahrungen machen müssen. Für mich reicht Max aber vollkommen aus. Es geht schnell und über iTunes habe ich Zugriff auf die Mediendatenbank Gracenote, in der anscheinend deutlich mehr klassische Werke verzeichnet sind, als bei MusicBrainz oder freedb.

VG Bernd

[Gisorg]

Hallo Uli,
dankeschön für deine Analyse.

A wird beim Entpacken 9592 kB gross. Es ist in der LIST-Information ein Coverbild enthalten, daher die Unterschiedliche Größe. Es sind bei DATA dieselbe Anzahl an Samples enthalten. ABER: A hat bei den ersten 696 Samples (stereo) eine andere Information. Dann hat A genau dieselbe Information wie B und C, hört aber logischerweise um die 696 Samples früher auf, da gleiche Länge.

In iTunes ist der Song ohne zeitlicher Limitierung eingestellt. Dabei fällt mir auf das eigentlich
jede Datei via iTunes ungleich dem von XML ist. Um genauer die Masse der Files zu vergleichen
müssten die Covers gelöscht werden. Falls trotzdem Unterschiede sind, dann ist schon bedenklich,
dass iTunes selbstständig beschneidet. Wie lange sind die 696 Samples als Millisekunden ausgedrückt?

[gregor]

Wie lange sind die 696 Samples als Millisekunden ausgedrückt?

Hallo Daniel,

die Rechnung ist einfach: N (Samples):Abtastrate in kHz, also 696:44,1. Anscheinend unterschlägt itunes knapp 16 ms.

Hat schon mal jemand überprüft, ob das auch bei itunes-interner Wandlung von ALAC auf AIFF bzw. zurück passiert? Vielleicht kann dann auch noch jemand ausrechnen, wie viel Lebenszeit man fürs Hin- und Herkonvertieren investieren müsste, um einen fünfzehnminütigen Satz komplett verschwinden zu lassen.

Übrigens: auch ich hatte noch nie Schwierigkeiten mit MAX.

Beste Grüße

gregor

[uli.brueggemann]

Wie lange sind die 696 Samples als Millisekunden ausgedrückt?

696/44100 = 15,78 ms

Gruss
Uli