EAC vs. AUDIOGRABBER

Ok. Heisst dann also, dass die Daten zum Pre-Emphasis in den Tags gespeichert werden und ich mein CD-Rip-Programm entsprechend einrichten muss? Oder eben, dass ich nachträglich das Pre-Emphasis hinzufüge...

Das müsste doch eigentlich jedes CD-Rip-Programm von Haus aus können, oder? Ist doch ein Witz, dass dies nicht standardmässig automatisch angewendet wird...!

Genau. Es gibt auch kein standardisiertes Tag dafür, auch wenn man Deemphasis-Plugins für Foobar über Tags steuern kann.

Zumindest EAC hat eine Spalte für PE, ganz hinten. Nützt aber auch nur was, wenn's in der TOC steht. PE nur im Subcode kann aber eh kein Ripper erfassen, schlicht weil der nicht mitgerippt wird.

Im Bereich Pop / Rock sind Emphasis-CDs zum Glück ziemlich rar. Ich habe ganze 3 Stück (von mehreren 100) durch einen Deemphasis-DSP jagen müssen, alle aus der Zeit 1982-85. Darunter waren die Brothers in Arms (Originalauflage) und Toto IV (CBS 450088 2).

Oh Mist, die Opera Sauvage und L'Apocalypse des Animaux von Vangelis sollen auch mit PE sein? Das muß ich glatt mal prüfen. Jo, die erstere (Polydor 929 663-2) behauptet, sie wäre mit PE. Die andere kann ich gerade nicht finden, scheint aber die 831 503-2 und damit wohl auch mit PE zu sein (würde passen, bißchen hochfrequentes Rauschen scheint drauf zu sein). Antarctica (Polydor 815 732-2) ist hingegen ohne, aber die ist auch (C) 1988. Naja, das wären dann jedenfalls 2 mehr.

Paesc (Beitrag #99) schrieb:

Hmm... In den Anleitungen zu EAC und Foobar steht nichts von einem Pre-Emphasis beim Rippen, auch wird nicht auf Plugins hingewiesen. Heisst das, dass nun meine Rips mit Foobar ohne irgend welche Emphasis-Informationen gerippt wurden? Mit was für Plugins kann man nachträglich wie auch beim Rippen das De-Emphasis erledigen?

EAC besitzt doch - ganz rechts - extra die "Pre-Emphasis"-Spalte, in der Dir angezeigt wird, ob ein Track Pre-Emphasis hat oder nicht. Gefüllt wird diese Spalte allerdings lediglich aufgrund des TOCs der CD und nicht des Subcodes, d.h. wenn diese Information im TOC fehlt (das ist bei einigen CDs so), erkennt EAC Pre-Emphasis einfach nicht. Wenn es sie erkennt, schreibt es allerdings auch einen entsprechenden Eintrag in das CUE-Sheet.

audiophilanthrop (Beitrag #103) schrieb:

PE nur im Subcode kann aber eh kein Ripper erfassen, schlicht weil der nicht mitgerippt wird.

Was heißt "mitrippen"? Du musst den Subcode ja nur auslesen und im CUE-Sheet einen "FLAGS PRE"-Eintrag hinzufügen - und das macht CUE-Ripper (im Gegensatz zu EAC oder dBPA) auch dann, wenn die PE nur im Subcode, aber nicht im TOC steht. Selbst iTunes ist dabei nicht auf das TOC angewiesen, sondern auch dem reicht der Subcode (und De-Empasizing wird dann bei Playback und Ripping automatisch angewendet).

Paesc (Beitrag #102) schrieb:

Das müsste doch eigentlich jedes CD-Rip-Programm von Haus aus können, oder? Ist doch ein Witz, dass dies nicht standardmässig automatisch angewendet wird...!

Das ist halt generell schon recht selten, kann Dir aber prinzipiell natürlich bei jedem alten Mastering passieren, das irgendwann mal wieder unverändert wiederveröffentlicht wird. Bei dem Anspruch, den dBPA als kostenpflichtiges Programm erhebt, ist das Fehlen einer solchen Unterstützung hier aus meiner Sicht allerdings ziemlich inakzeptabel.

ist foobar da eigentlich immer noch auf die veraltete Version 1 beschränkt?)

Katastrophe, ich bin schier verzweifelt, als ich meine 2400 CDs zuerst mit Foobar geprüft habe. Selbst populäre CDs (bei Klassik zB fast alle Karajan, Solti ...) haben teilweise gefehlt.
Erst mit CueTools bin ich dann auf ca 95% Erkennung gekommen (was Originale und am PC gerippte betrifft, bei Audiobrenner klappt es nicht, auch nicht bei Bitidentität, weil die bei jedem Track unterschiedliche Offsets machen, sodass die CD nicht gefunden werden kann)...

Auch mit der AC2 kommt man nicht weit, extrem viele sind nur in der CUE-Datenbank......
Unter diesem Aspekt ist Foobar wirklich zum Vergessen.

PS: Seit Jänner kann Foobar Bitcompare auch Offsets berücksichtigen, das ist wenigstens etwas, das man manchmal braucht.

audiophilanthrop (Beitrag #103) schrieb:

Genau. Es gibt auch kein standardisiertes Tag dafür, auch wenn man Deemphasis-Plugins für Foobar über Tags steuern kann. Zumindest EAC hat eine Spalte für PE, ganz hinten. Nützt aber auch nur was, wenn's in der TOC steht. PE nur im Subcode kann aber eh kein Ripper erfassen, schlicht weil der nicht mitgerippt wird.

Hmm... Das macht's dann umso komplexer. Dann gibt es keinen Plattform- resp. Programm-übergreifenden Standard, der in die Tags geschrieben werden kann?

CUE-Sheets hab ich nie erstellt... Bei mir muss jedes einzelne FLAC-File für sich "eigenständig" sein, so kann ich auch problemlos Zusammenstellungen machen. Daher habe ich auch die Album-Cover in jedes Lied eingebettet.

audiophilanthrop (Beitrag #103) schrieb:

Im Bereich Pop / Rock sind Emphasis-CDs zum Glück ziemlich rar. Ich habe ganze 3 Stück (von mehreren 100) durch einen Deemphasis-DSP jagen müssen, alle aus der Zeit 1982-85. Darunter waren die Brothers in Arms (Originalauflage) und Toto IV (CBS 450088 2).

Wenigstens etwas. Aber genau die Erstausgabe von Dire Straits - Brothers In Arms hab ich Mist...

Wie erkenne ich eigentlich mit Foobar, ob eine CD Emphasis hat? Sorry, Emphasis ist für mich ein komplett neues Kapitel, hab ich nie beachtet... Aber es gibt sogar moderne CD-Player (selbst im High-End-Bereich), die Emphasis nicht beachten

shaboo (Beitrag #106) schrieb:

Bei dem Anspruch, den dBPA als kostenpflichtiges Programm erhebt, ist das Fehlen einer solchen Unterstützung hier aus meiner Sicht allerdings ziemlich inakzeptabel.

Dem kann ich nur zustimmen...!

Das müsste doch eigentlich jedes CD-Rip-Programm von Haus aus können, oder? Ist doch ein Witz, dass dies nicht standardmässig automatisch angewendet wird...!

Schuld daran ist aber v.a. der CD-Hersteller: Warum zum Kuckuck hat es Denon nicht im TOC abgelegt?
Besonders lästig ist das, wenn es bei jedem Track anders ist, mal mit, mal ohne, und nix davon im TOC.....

Gibts nicht? Gibts schon: zB bei alten Samplern kann das der Fall sein (habe zB so einen Sony-Musik-Sampler aus 1983, weiß aber nicht, obs dort auch im TOC war, habe ihn nicht mehr)), oder zB bei der Denon Audio Technical Test CD, weil man ja auch diverse Dinge mit Emphasis messen muss...((hier definitiv nicht im TOC)

Paesc (Beitrag #108) schrieb:

Wenigstens etwas. Aber genau die Erstausgabe von Dire Straits - Brothers In Arms hab ich Mist...

Wenn man's weiß, ist es ja kein Hit. Den Converter mit foo_dsp_deemph drüberjagen, vorher ein Tag "PRE_EMPHASIS" o.ä. mit Inhalt "1", "on" oder "yes" einfügen, Output am besten FLAC in 24 Bit oder so, beim Konverter-Output das Tag wieder entsorgen (sonst würde die Postprocessing-Version des Plugins bei Wiedergabe gleich nochmal Deemphasis drauf anwenden, und das wäre ja Unfug).

Die Brothers in Arms (wer hat die eigentlich nicht?) ist übrigens ein Sonderfall, weil die Preemphasis nirgends vermerkt ist, das ganze ist aber schon "qua Ohrenschein" recht höhenlastig, auch im Vergleich zum '96er Remaster.

Paesc (Beitrag #108) schrieb:

Wie erkenne ich eigentlich mit Foobar, ob eine CD Emphasis hat?

Öhm... Gar nicht?

audiophilanthrop (Beitrag #110) schrieb:

Die Brothers in Arms (wer hat die eigentlich nicht?) ist übrigens ein Sonderfall, weil die Preemphasis nirgends vermerkt ist, das ganze ist aber schon "qua Ohrenschein" recht höhenlastig, auch im Vergleich zum '96er Remaster.

Ist das eigentlich allgemeiner Konsens, dass ausnahmslos alle nicht-remasterten BiA-Fassungen bis 1995 PE haben, auch wenn weder in TOC noch Subcode vermerkt?

cr (Beitrag #109) schrieb:

Das müsste doch eigentlich jedes CD-Rip-Programm von Haus aus können, oder? Ist doch ein Witz, dass dies nicht standardmässig automatisch angewendet wird...! Schuld daran ist aber v.a. der CD-Hersteller: Warum zum Kuckuck hat es Denon nicht im TOC abgelegt? Besonders lästig ist das, wenn es bei jedem Track anders ist, mal mit, mal ohne, und nix davon im TOC.....

Dann ist die Thematik wohl sehr Komplex...

audiophilanthrop (Beitrag #110) schrieb:

...Output am besten FLAC in 24 Bit oder so...

Ist's dann noch eine bit-genaue "1:1-Kopie", die auch mit CUETools als "akkurat" eingestuft warden würde? Ich glaube nicht, meines Wissens funktioniert AccurateRip nur mit 16-Bit-Material...

audiophilanthrop (Beitrag #110) schrieb:

Die Brothers in Arms (wer hat die eigentlich nicht?) ist übrigens ein Sonderfall, weil die Preemphasis nirgends vermerkt ist, das ganze ist aber schon "qua Ohrenschein" recht höhenlastig, auch im Vergleich zum '96er Remaster.

Das kannst Du laut sagen... Höhenlastig ist bloss der Vorname! Ich mag die Remaster von 1996 wie auch die Hybrid-SACD viel mehr. Der schwache Bass wurde ausgeglichen, endlich hat die Aufnahme "Dampf", und die Höhenlast wurde erträglich gemacht; die Ohren bluten nicht mehr nach dem Hören. Was für ein Segen...

audiophilanthrop (Beitrag #110) schrieb:

Paesc (Beitrag #108) schrieb: Wie erkenne ich eigentlich mit Foobar, ob eine CD Emphasis hat? Öhm... Gar nicht?

Dann muss man wohl selber wissen, ob Emphasis vorhanden ist oder nicht... Gott sei Dank ist Emphasis eine Seltenheit und gehört der Vergangenheit an...

Paesc (Beitrag #112) schrieb:

Ist's dann noch eine bit-genaue "1:1-Kopie", die auch mit CUETools als "akkurat" eingestuft warden würde? Ich glaube nicht, meines Wissens funktioniert AccurateRip nur mit 16-Bit-Material...

Sobald Du irgendwas mit den gerippten Daten anstellst (HDCD-Konvertierung in 20/24 Bit, De-Emphasizing, Normalisierung, ...) ist der Kram nicht mehr 1:1 und auch mit keiner Datenbank mehr verifizierbar, völlig unabhängig davon, ob in 16-, 20- oder 24-Bit-Format.

Paesc (Beitrag #112) schrieb:

Dann muss man wohl selber wissen, ob Emphasis vorhanden ist oder nicht...

Wie gesagt, Du kannst einfach CUE-Ripper verwenden und ins CUE-Sheet schauen oder EAC in der Version 0.95 Prebeta 3 (oder früher) und dessen manuelle TOC-Erkennung verwenden. Natürlich brauchst Du dazu immer die physische CD.

Gut zu wissen, danke. Ich möchte meine Dateien eigentlich schon originalgetreu halten. Werd's mir aber überlegen... Das mit dem Emphasis ist schon ein Witz, sollte in gerippten Files eigentlich korrigiert werden. Wenn Emphasis auf solch verschiedene und mitunter auch verwirrende Weise gesetzt wird, wird wohl auch so mancher CD-Player verwirrt werden.

Habe die "Originalfiles" (ohne Album Cover und irgendwelche DSP-Veränderungen) genau für solche Überlegungen aufbehalten.

Der Redbook-konforme CDP wird überhaupt nicht verwirrt, denn er richtet sich nur nach dem Subcode.
Ansonsten wäre nicht das Brennen CDP > Audiobrenner der Problemlöser: Die gebrannte CDR hat dann nämlich alle Subcodes auch im TOC, weil sie der Audiobrenner dort reinschreibt (zusätzlich zum Subcode, den er auch übernimmt). So habe ich mir von den Denon-Test-CDs Kopien erstellt, die man dann Emphasis-korrekt auch am PC brennen kann (jetzt gehts ja auch so mit den paar wenigen Tools, die das angeblich richtig erkennen).

Für Nicht-Klassik-Hörer ist das ganze eh nicht so wichtig, denn außer Brothers in Arm und Dark Side of the Moon (EMI Japan, 1985 oder so) gibt es in diesem Genre nicht viel, und immer nur einzelne Pressungen

Hier eine Liste dazu: PREEMPHASISLISTE

http://www.studio-ni...asis_(release_list)#

Sind ja zum Glück nur sehr wenige CDs. Ich geh mal davon aus, dass die Remaster nicht betroffen sind von Emphasis. 2 von der Liste hab ich:
- Dire Straits - Brothers In Arms (Original und Remaster 1996 und Hybrid-SACD 2005)
- Barclay James Harvest - Turn Of The Tide (Remaster 2013)

Ich glaube das Problem hier ist, dass Du nicht verstehst - oder nicht nicht verstehen willst, warum eigentlich kein Mensch mehr in WAV rippt. Das Killerargument ist dabei die Tatsache, das WAV keinerlei Tags unterstützt. Was soll ich denn mit einer großen, tollen, digitalisierten Musiksammlung machen, wenn ich noch nichtmal einfachste Dinge, wie das Sortieren nach Genre, Erscheinungsjahr, etc. machen kann?

Gerade wenn es um die neue Flamme geht, ist die einfache Zugänglichkeit der Musiksammlung meist der entscheide Punkt. Ich formulier es jetzt extra mal etwas klischeebehaftet: Wenn Du deine Musiksammlung so organisiert hast, dass Sie mit Ihrem Smartphone sofort den Durchblick hat (also z. b. die Sammlung mit beliebigen Player-Apps durchsuchen und anhören kann), biste Medienexperte und sie wird deine Sammlung auch mit hören.
Haste dagegen die Sachen nur als WAV vorliegen, ist die leichte Bedienbarkeit nicht gegeben. Alle Medienplayer - egal ob PC-Software, Smartphone-Apps oder auch spezielle Hardwareplayer - durchsuchen und sortieren die Mediensammlung anhand der Tags! Haste keine Tags, machts keinen Spaß. Die neue Flamme wirds als zu kompliziert abstempeln und Du kannst die Sammlung allein hören..

Das ist der Grund, warum es keinen Sinn macht in WAV zu rippen..

Das ist deine etwas einseitige Sicht der Dinge.
Wenn man alles in einer Ordnerstruktur angelegt hat, findet man trotzdem alles sofort.....
Habe zwar inzwischen alles in FLAC, keine Tags (und es wird auch nie welche geben), und finde trotzdem alles, und nicht nur ich.....

Auf Tags als einziges Ordnungskriterium würde ich nicht vertrauen. Wäre nicht das erste Mal, dass dann ein neuer Player die Tags nicht mehr in der vorhandenen Form lesen kann.

Gut, das wäre dann doch wieder ein Argument für die alleinige Sortierung über die Ordnerstruktur. Ich will ja nicht ausschließen, dass ich da auch noch was dazulernen muss..

Man kann (sollte) auch beides machen, die TAGs stören ja nicht die Ordnerstruktur.
Eine große Musiksammlung ohne sinnvolle Ordnerstruktur, nur mit TAGs, darauf würde ich nicht vertrauen....

Con-Hoolio (Beitrag #118) schrieb:

Ich glaube das Problem hier ist, dass Du nicht verstehst - oder nicht nicht verstehen willst, warum eigentlich kein Mensch mehr in WAV rippt. Das Killerargument ist dabei die Tatsache, das WAV keinerlei Tags unterstützt. Was soll ich denn mit einer großen, tollen, digitalisierten Musiksammlung machen, wenn ich noch nichtmal einfachste Dinge, wie das Sortieren nach Genre, Erscheinungsjahr, etc. machen kann?

Wen meintest Du? Mich? Ich wüsste nicht, wer hier noch in WAV rippen würde... Ich hab's nie getan, andere sind auf FLAC umgesattelt.

Bitte um klarere Posts, nicht einfach Beschuldigungen in den Raum stellen.

Gut, das habe ich auch nicht gemacht. Ich würde auch auch nicht komplett ohnr Tags auskommen wollen. Ich habe bei mir auch die Couver-Bilchen in die FLAC-Tags mit eingebunden. So werden die jetzt im Kodi zuverlässiger mit angezeigt.

Paesc (Beitrag #122) schrieb:

Wen meintest Du? Mich? Ich wüsste nicht, wer hier noch in WAV rippen würde... Ich hab's nie getan, andere sind auf FLAC umgesattelt. Bitte um klarere Posts, nicht einfach Beschuldigungen in den Raum stellen.

Lies halt mal den Anfang des Threads, dann weisst du auch, an wen diese Zeilen gerichtet waren.

shaboo (Beitrag #111) schrieb:

Ist das eigentlich allgemeiner Konsens, dass ausnahmslos alle nicht-remasterten BiA-Fassungen bis 1995 PE haben, auch wenn weder in TOC noch Subcode vermerkt?

Zumindest Version C hat, das ist nämlich meine, inkl. Datenfehler in My Latest Trick (habe ich übrigens vor der Deemphasis mit CUETools rauskorrigieren lassen). Version A dann vermutlich auch. B und D, keine Ahnung. Sollen ja sowieso von vornherein zwei verschiedene Masterings im Umlauf gewesen sein. BIAlogie... da blicke noch einer durch...

shaboo (Beitrag #113) schrieb:

Sobald Du irgendwas mit den gerippten Daten anstellst (HDCD-Konvertierung in 20/24 Bit, De-Emphasizing, Normalisierung, ...) ist der Kram nicht mehr 1:1 und auch mit keiner Datenbank mehr verifizierbar, völlig unabhängig davon, ob in 16-, 20- oder 24-Bit-Format.

Wobei das in dem Moment wurscht sein sollte, dann man hat es ja vorher schon verifiziert. Und bei den paar Alben ist es auch nicht schlimm, wenn man zusätzlich das Okinal unverändert aufhebt.

altae (Beitrag #124) schrieb:

Lies halt mal den Anfang des Threads, dann weisst du auch, an wen diese Zeilen gerichtet waren.

Mittendrin nach zig Posts ohne Zitat ein altes Thema aufzugreifen ist dann doch recht ungeschickt und führt zu Missverständnissen. Genau deshalb wurde die Zitierfunktion eingeführt, um dem vorzubeugen.

Einfach nur den Schluss lesen und sich dann betroffen fühlen ist auch ungeschickt

Hab mich da eingeklinkt, wo's interessant war und dem Thema entsprach: was ist die beste CD-Rip-Software Muss ja alte Brühe nicht aus Langeweile aus dem Nichts wieder aufwärmen...

Back to topic...

Moin.
Der TE sagt mal Danke für die rege Beteiligung bisher.
Mir ist das aber mittlerweile viel zu kompliziert geworden.
Was eine Entscheidung sicher nicht leichter gemacht hat.
Was ich für mich heraus filtere ist,
dass FLAC wie WAV ist. Nur kleiner, durch Komrimierung.
Wie das komprimieren ohne Daten- bzw. Qualitätsverlust funktioniert konnte ich aus dem Thread nicht
ersehen. Ist für meine Bedürfnisse am Ende aber unwichtig.
Wie sagte doch gleich jemand: "Bei mir kommt der Strom aus der Steckdose."
Da ich über 30 Jahre in der Kerntechnik gearbeitet habe,
könnte ich sicher erläutern wie er dahin kommt.
Um ein Ei zu kochen ist das aber IMHO nicht SO wichtig.
JSJ

P.S.
Kann meinetwegen geschlossen werde.

JÄGERSCHNITZELJÄGER (Beitrag #129) schrieb:

Wie das komprimieren ohne Daten- bzw. Qualitätsverlust funktioniert konnte ich aus dem Thread nicht ersehen.

Da kommen viele Sachen zusammen. Z.B. speichert Wave alle Kanäle einzeln - bei einer perfekten Monoaufnahme kann aber ein Kanal komplett wegfallen (in der Realität wird eher der Unterschied zwischen zwei Kanälen angegeben - und je kleiner der ist, umso besser lässt es sich komprimieren). Dann wird nach Wiederholungen gesucht etc.

Vereinfacht gesagt: statt 44100 Nullen zu schreiben, könnte ich auch einfach "1s Stille" sagen. Das kürzt den Text enorm, ohne Informationsgehalt zu verlieren.

Ganz simpel: Im Prinzip so: Es wird nicht alle 1/44.000 Sekunden der volle Zahlenwert gespeichert, sondern nur die Differenz zum Vorhergehenden.

zB statt

300, 302, 305, 300, 295 nur:
300, +2, +3, -5, -5. Dabei geht nichts verloren und man braucht weniger Platz.

Siehe z.B. FLAC format bzw. About the FLAC format.

Hervorzuheben wären vor allem Interchannel Decorrelation (die schon erwähnte Konvertierung von (L,R) in Mid-Side, also ((L+R)/2,(L-R)/2) - der Differenzterm ist i.d.R. deutlich leiser und damit sparsamer zu encoden) sowie Prediction (einfache Näherung des Signalverlaufs) + Residual Coding (Speichern der Differenz zum realen Verlauf).
EDIT: Also genau das:

cr (Beitrag #131) schrieb:

zB statt 300, 302, 305, 300, 295 nur: 300, +2, +3, -5, -5.

"+300" braucht 1+9 = 10 Bits. "-5" aber nur noch 1+3 = 4 Bit.
/EDIT

Leider pflegt der Schritt von 16 zu 24 Bit pro Sample die resultierende Datenmenge erheblich aufzublähen. Aber das ist auch irgendwo zu erwarten, weil dann natürlich das Rauschen erheblich feiner aufgelöst vorliegt und man einem verlustfreien Codec schwerlich sagen kann, daß einen das vielleicht gar nicht interessiert. Überhaupt fußt der Erfolg solcher Kompressionsverfahren darauf, daß typische Audiosignale recht gut vorhersagbar sind und nicht immer die gesamte verfügbare Dynamik ausnutzen. Sehr lauter, rauschähnlicher Input kann die Ausgangs-Datenrate durchaus sogar über das Eingangsniveau steigen lassen. Auch das typisch für ein verlustfreies Verfahren. So wie jene Dateien, die gepackt sogar einen Hauch größer sind.

Übrigens kann man auch WAVs in ein ZIP o.ä. schmeißen, nur wird der Erfolg bei normalem Musikmaterial eher bescheiden ausfallen. Da sind FLAC und Co. mit ihrem "Insiderwissen" einfach besser aufgestellt. Aber keine Regel ohne Ausnahme - so Sachen wie Sinustöne werden als gepackte WAVfel richtig klein, vermutlich der Periodizität wegen (ein gefundenes Fressen für klassische Packalgorithmen, die nach genau sowas suchen).

audiophilanthrop (Beitrag #132) schrieb:

Sehr lauter, rauschähnlicher Input kann die Ausgangs-Datenrate durchaus sogar über das Eingangsniveau steigen lassen. Auch das typisch für ein verlustfreies Verfahren. So wie jene Dateien, die gepackt sogar einen Hauch größer sind.

Aber sind das nicht tendenziell eher konstruierte als wirklich praxisrelevante Fälle (so ähnlich wie die Killersamples für die Artefakte bei MP3-Komprimierung)? Zwar lässt sich mathematisch beweisen, dass ein Komprimierungsalgorithmus, der einige Inputs kleiner macht, zwangsläufig andere Inputs größer machen muss, aber das lässt sich ja in der Praxis leicht umgehen. Zum einen sollte ein solcher Algorithmus nur solche Teile eines Inputs zu komprimieren versuchen, in denen er auch tatsächlich irgendeine Art von Regelmäßigkeit in den Daten feststellt. Anderenfalls sollten die Daten unkomprimiert übernommen werden. Außerdem lässt sich ja ohne nennenswerten Overhead ein Test einbauen, der überprüft, ob der finale Output tatsächlich kleiner ist als der Input, und in diesem Falle einfach den unveränderten Input als Resultat ausspuckt. So was würde ich von jedem halbwegs intelligenten Komprimierungsprogramm eigentlich erwarten. (Streng genommen ist der Output dann immer noch minimal größer als der Input, weil dem Dekomprimierungsprogramm natürlich irgendwie signalisiert werden muss, dass der Input einfach unverändert übernommen werden soll, aber das sind dann wirklich nur ein paar Byte).

Was da los, die CD sieht optisch top aus, bekam ich heute, wiedermal feines HiFi geschossen auf eBay

Exact Audio Copy V1.1 from 23. June 2015 EAC Auslese-Logdatei vom 5. November 2015, 15:01 Elvis Presley / Love Me Tender - 20 Love Songs Benutztes Laufwerk : HL-DT-STDVDRAM GSA-H10N Adapter: 1 ID: 1 Lesemodus : Sicher Benutze Accurate Stream : Ja Audio Puffer abgeschaltet : Nein Benutze C2 Fehlerinformationen : Ja Leseoffset Korrektur : 667 Überlesen in das Lead-In und Lead-Out : Nein Fülle fehlende Offsetsample mit Stille auf : Ja Lösche führende und nachfolgende stille Blöcke : Nein Null Samples gehen in CRC Berechnungen ein : Ja Benutzte Schnittstelle : Natürliche Win32 Schnittstelle für Win NT/2000/XP Pausenbehandlung : Nicht erkannt, daher hinter dem vorigen Track angehängt Benutztes Ausgabeformat : Benutzerdefinierter Komprimierer Gewählte Bitrate : 1024 kBit/s Qualität : Hoch Füge ID3 Tag hinzu : Nein Kommandozeilen Komprimierer : C:\Program Files (x86)\Exact Audio Copy\Flac\fpFLAC.exe Zusätzliche Kommandozeilenoptionen : -8 -V -T "ARTIST=%artist%" -T "TITLE=%title%" -T "ALBUM=%albumtitle%" -T "DATE=%year%" -T "TRACKNUMBER=%tracknr%" -T "GENRE=%genre%" -T "COMMENT=%comment%" -T "BAND=%albuminterpret%" -T "COMPOSER=%composer%" -T "DISCNUMBER=%cdnumber%" -T "TOTALDISCS=%totalcds%" -T "TOTALTRACKS=%numtracks%" -f %source% %dest% TOC der ausgelesenen CD Track | Start | Länge | Startsektor | Endsektor ------------------------------------------------------- 1 | 0:00.32 | 3:16.40 | 32 | 14771 2 | 3:16.72 | 2:44.38 | 14772 | 27109 3 | 6:01.35 | 2:37.10 | 27110 | 38894 4 | 8:38.45 | 2:49.10 | 38895 | 51579 5 | 11:27.55 | 2:59.50 | 51580 | 65054 6 | 14:27.30 | 2:08.02 | 65055 | 74656 7 | 16:35.32 | 2:31.58 | 74657 | 86039 8 | 19:07.15 | 2:26.05 | 86040 | 96994 9 | 21:33.20 | 2:10.02 | 96995 | 106746 10 | 23:43.22 | 2:43.60 | 106747 | 119031 11 | 26:27.07 | 3:08.63 | 119032 | 133194 12 | 29:35.70 | 1:52.62 | 133195 | 141656 13 | 31:28.57 | 2:29.05 | 141657 | 152836 14 | 33:57.62 | 2:22.40 | 152837 | 163526 15 | 36:20.27 | 2:31.70 | 163527 | 174921 16 | 38:52.22 | 2:41.53 | 174922 | 187049 17 | 41:34.00 | 2:02.45 | 187050 | 196244 18 | 43:36.45 | 3:23.62 | 196245 | 211531 19 | 47:00.32 | 2:15.55 | 211532 | 221711 20 | 49:16.12 | 2:14.65 | 221712 | 231826 .... Track 9 Dateiname D:\_Datentemp\Elvis Presley - Love Me Tender - 20 Love Songs\09 - Elvis Presley - She's Not You.wav Spitzenpegel 79.3 % Auslesegeschwindigkeit 3.9 X Track Qualität 98.0 % Kopie CRC 23251D0F Kann nicht als akkurat verifiziert werden (Zuversicht 6) [3BBC4FB4], AccurateRip lieferte [7F42B8BE] (AR v2) Kopie OK Track 10 Dateiname D:\_Datentemp\Elvis Presley - Love Me Tender - 20 Love Songs\10 - Elvis Presley - I Love You Because.wav Spitzenpegel 90.5 % Auslesegeschwindigkeit 7.3 X Track Qualität 98.9 % Kopie CRC 30A9CAAD Kann nicht als akkurat verifiziert werden (Zuversicht 6) [7D0FFF18], AccurateRip lieferte [A0E43165] (AR v2) Kopie OK 18 Track(s) akkurat gelesen 2 Track(s) nicht als akkurat verifiziert Einige Tracks konnten nicht als akkurat verifiziert werden Keine Fehler aufgetreten Ende des Statusreports ---- CUETools DB Plugin V2.1.6 [CTDB TOCID: 0bWyG7Ikgkab7uRWKVa_Re.NSuc-] found Submit result: 0bWyG7Ikgkab7uRWKVa_Re.NSuc- has been submitted Track | CTDB Status 1 | (6/6) Accurately ripped 2 | (6/6) Accurately ripped 3 | (6/6) Accurately ripped 4 | (6/6) Accurately ripped 5 | (6/6) Accurately ripped 6 | (5/6) Accurately ripped 7 | (6/6) Accurately ripped 8 | (6/6) Accurately ripped 9 | (1/6) Differs in 34 samples @00:22:40,00:32:66,00:33:18,00:33:73,00:34:12,00:34:67,00:38:25,00:56:42,00:59:22,00:59:50,01:02:31,01:07:13,01:08:33,01:17:47,01:26:05,01:56:25,02:02:47,02:03:13,02:06:25, or (3/6) differs in 34 samples @00:22:40,00:32:66,00:33:18,00:33:73,00:34:12,00:34:67,00:38:25,00:56:42,00:59:22,00:59:50,01:02:31,01:07:13,01:08:33,01:17:47,01:26:05,01:56:25,02:02:47,02:03:13,02:06:25 10 | (1/6) Differs in 18 samples @00:05:45,00:08:15,00:21:74,00:22:41,00:22:55,00:23:50,00:25:26, or (3/6) differs in 18 samples @00:05:45,00:08:15,00:21:74,00:22:41,00:22:55,00:23:50,00:25:26 11 | (4/6) Accurately ripped 12 | (5/6) Accurately ripped 13 | (4/6) Accurately ripped 14 | (5/6) Accurately ripped 15 | (5/6) Accurately ripped 16 | (6/6) Accurately ripped 17 | (6/6) Accurately ripped 18 | (5/6) Accurately ripped, or (1/6) differs in 12 samples @03:22:73 19 | (6/6) Accurately ripped 20 | (6/6) Accurately ripped If you are sure that your rip contains errors, you can use CUETools to repair it.

Gruss Dennis

Und deswegen stellst du deine elendslange Logliste ein, nur weil 2 Tracks nicht akkurat sind? Gehts noch?
Die CD hat halt in der Mitte Fehler, und? Soll vorkommen!

cr (Beitrag #135) schrieb:

Und deswegen stellst du deine elendslange Logliste ein, nur weil 2 Tracks nicht akkurat sind? Gehts noch? Die CD hat halt in der Mitte Fehler, und? Soll vorkommen!

sry, hab den mal eben gekürzt, schaut anscheinend nicht jeder über einen recht grossen Bildschirm am Rechner mit 1080p an

Joa ich denke mal wenn da wirklich was "am Bach" sein sollte, wird das wohl eindeutig hörbar sein, hatte sowas mal mit einer alten "Dune" CD, kein HiFI, aber Kulturgut

Gruss Dennis

Es gibt überhaupt kein Problem

9 | (1/6) Differs in 34 samples @00:22:40,00:32:66,00:33:18,00:33:73,00:34:12,00:34:67,00:38:25,00:56:42,00:59:22,00:59:50,01:02:31,01:07:13,01:08:33,01:17:47,01:26:05,01:56:25,02:02:47,02:03:13,02:06:25, or (3/6) differs in 34 samples @00:22:40,00:32:66,00:33:18,00:33:73,00:34:12,00:34:67,00:38:25,00:56:42,00:59:22,00:59:50,01:02:31,01:07:13,01:08:33,01:17:47,01:26:05,01:56:25,02:02:47,02:03:13,02:06:25
10 | (1/6) Differs in 18 samples @00:05:45,00:08:15,00:21:74,00:22:41,00:22:55,00:23:50,00:25:26, or (3/6) differs in 18 samples @00:05:45,00:08:15,00:21:74,00:22:41,00:22:55,00:23:50,00:25:26

Das heißt, es gibt 5 Übereinstimmungen oder 3 Übereinstimmungen , Fall gelöst.
1 oder 3 Ripergebniss sind halt falsch, 5 oder 3 sind richtig.

Dennis50300 (Beitrag #134) schrieb:

Was da los, die CD sieht optisch top aus, bekam ich heute, wiedermal feines HiFi geschossen auf eBay

Die beiden nicht-verifizierbaren Tracks 9 und 10 sind gleichzeitig auch die einzigen, deren Track-Qualität signifikant unter 100% liegt (wobei 98,0 und 98,9 Prozent nicht so signifikant aussehen, es für EAC-Verhältnisse aber sind) und bei denen auch die Auslesegeschwindigkeit (aufgrund der wiederholten Leseversuche) drastisch geringer ist als bei den anderen Tracks. Da Du den Secure-Modus verwendet hast, sollten EAC eigentlich mindestens zwei Lesevorgänge mit übereinstimmendem Resultat gelungen sein, aber gelegentlich führt auch das nicht immer zu perfekten Resultaten.

Solche Probleme konnte ich (sofern die CD nicht tatsächlich physisch irreparabel beschädigt war) zuverlässig durch eine der folgenden drei Maßnahmen beheben:

1) EAC im Burst-Modus lesen lassen, Test & Copy verwenden und auf übereinstimmende Checksummen achten. In solchen Fällen, wie dem obigen, musst Du ja nur die Tracks 9 und 10 neu auslesen. (Gelegentlich lassen sich CDs im Burst-Modus tatsächlich am besten auslesen.) Danach liefert Dir AR meist ein besseres Ergebnis.

2) EAC auf eine höhere Fehlerkorrekturstufe stellen.

3) Mit anderem Laufwerk rippen.

Die 2 Tracks ggf. nochmals rippen und beide Ergebnisse mit Foocompare vergleichen. Sind sie identisch. liegt 100% kein Fehler auf der CD vor.

Liegt doch ein Fehler vor: Mit Cuetools habe ich schon größere Fehler repariert.

cr (Beitrag #137) schrieb:

Es gibt überhaupt kein Problem 9 | (1/6) Differs in 34 samples @00:22:40,00:32:66,00:33:18,00:33:73,00:34:12,00:34:67,00:38:25,00:56:42,00:59:22,00:59:50,01:02:31,01:07:13,01:08:33,01:17:47,01:26:05,01:56:25,02:02:47,02:03:13,02:06:25, or (3/6) differs in 34 samples @00:22:40,00:32:66,00:33:18,00:33:73,00:34:12,00:34:67,00:38:25,00:56:42,00:59:22,00:59:50,01:02:31,01:07:13,01:08:33,01:17:47,01:26:05,01:56:25,02:02:47,02:03:13,02:06:25 10 | (1/6) Differs in 18 samples @00:05:45,00:08:15,00:21:74,00:22:41,00:22:55,00:23:50,00:25:26, or (3/6) differs in 18 samples @00:05:45,00:08:15,00:21:74,00:22:41,00:22:55,00:23:50,00:25:26 Das heißt, es gibt 5 Übereinstimmungen oder 3 Übereinstimmungen , Fall gelöst. 1 oder 3 Ripergebniss sind halt falsch, 5 oder 3 sind richtig.

Woraus liest Du das denn? Die Ausgabe ist doch ziemlich eindeutig: Für Track 9 liegen in der Datenbank vier Rips mit zwei verschiedene Checksummen vor, die sich jedoch beide von der gerippten CD unterscheiden. Für Track 10 gilt dasselbe. Gäbe es hier irgendwelche Übereinstimmungen, stünde bei den Tracks 9 und 10 auch irgendwo ein Eintrag der Gestalt "(x/y) Accurately ripped".

EDIT: Verwirrend ist, dass es bei beiden Tracks noch jeweils zwei weitere Checksummenübermittlungen gab (zu erkennen an dem "(x/6)"), die in obigem Protokoll aber einfach unter den Tisch fallen. Sie stimmen nicht mit unserem Rip überein (sonst würden sie oben als "(x/6) Accurately ripped" auftauchen) und es ist auch nicht bekannt, in wie vielen Samples sie sich von unserem Rip unterscheiden (sonst würden sie oben als "(x/6) Differs in y samples" auftauchen). Hier wäre es der Vollständigkeit halber definitiv sinnvoll, für beide Tracks noch einen Eintrag der Gestalt "(2/6) Differs in unknown number of samples" oder eben einfach nur "(2/6) Differs" hinzuzufügen.

Wenn 1/6 sich unterscheiden, stimmen 5/6 überein, elementare Logik.
Wenn 3/6 sich unterschieden, stimmen 3/6 überein, elementare Logik

Verknüpft man beide Aussagen mit ODER, stimmen mindestens 2/6 überein.

Gäbe es hier irgendwelche Übereinstimmungen, stünde bei den Tracks 9 und 10 auch irgendwo ein Eintrag der Gestalt "(x/y) Accurately ripped".

Stimmt, da ist auch was dran, es müßte noch stehen 2/6 ACR

cr (Beitrag #141) schrieb:

Wenn 1/6 sich unterscheiden, stimmen 5/6 überein, elementare Logik. Wenn 3/6 sich unterschieden, stimmen 3/6 überein, elementare Logik Verknüpft man beide Aussagen mit ODER, stimmen mindestens 2/6 überein.

... nur dass die Dinger leider nicht mit ODER, sondern mit Exklusiv-ODER verknüpft sind, was übrigens auch total sinnvoll ist, da alles andere nur unnötig verwirren würde. Das Protokoll gibt Dir einfach für alle in der Datenbank vorhandenen Checksummen den Grad der Übereinstimmung an. Gibt es beispielsweise drei Checksummen und jede Checksumme wird durch jeweils zehn Rips gestützt, wird die Ausgabe typischerweise eine Gestalt haben wie

(10/30) Accuratey ripped, or
(10/30) Differs in x samples, or
(10/30) Differs in y samples.

JA, ich habs mit so einer Angabe verwechselt:
8 | (3/4) Accurately ripped, or (1/4) differs in 11 samples @03:38:29,04:01:50,04:14:13

Fraglos verwirrend an der Ausgabe sind Zeilen wie diese:

6 | (5/6) Accurately ripped
...
18 | (5/6) Accurately ripped, or (1/6) differs in 12 samples @03:22:73

Bei Track 18 sagt uns das Protokoll genau, dass zwei verschiedene Checksummen existieren, wobei eine durch fünf und eine durch einen Rip gestützt wird. Unser Rip stimmt mit der durch fünf Rips gestützten Checksumme überein und unterscheidet sich von dem zur anderen Checksumme gehörigen Rip in zwölf Samples.

Bei Track 6 hingegen wissen wir nur, dass zwei verschiedene Checksummen existieren, wobei eine durch fünf und eine durch einen Rip gestützt wird.
Auch hier stimmt unser Rip mit der durch fünf Rips gestützten Checksumme überein, aber es gibt keine Informationen zu der abweichenden Anzahl an Samples im Vergleich zur zweiten Checksumme. Wieso diese Sample-Informationen mal vorhanden und mal nicht vorhanden sind, ist mir auch nicht bekannt. Ich schätze mal, das liegt daran, dass die genaue Anzahl unterschiedlicher Samples aus den Checksummen alleine nicht berechnet werden kann, sondern dass hierfür zusätzliche Informationen benötigt werden (genau dieselben, die auch bei der Reparatur eines Rips verwendet werden), die jedoch nicht immer in ausreichender Zahl verfügbar sind.

Habe jetzt mit der Suchfunktion meine 2000 Protokolle überprüft auf "differs":
Bei einem bin ich in der Tat darauf reingefallen, entsprechend meinen vorigen obigen Ausführungen, ist nicht akkurat......, obwohl ich es fälschlich dafür gehalten habe....

JÄGERSCHNITZELJÄGER (Beitrag #129) schrieb:

Was ich für mich heraus filtere ist, dass FLAC wie WAV ist. Nur kleiner, durch Komrimierung.

In einigen Beiträgen wurde versucht, Dir das Konzept der Tags näher zu bringen, was offensichtlich überhaupt nicht gelungen ist. Das ist bedauerlich, weil da das eigentliche Potenzial von "Computer Audio" liegt, und man dieses Potenzial mit wav a) nicht nutzen und b) später nur mit extrem viel Aufwand und/oder Glück nutzbar machen kann. Weil nicht vorhandene Metadaten eben nicht da sind.

Was das Schließen dieses Threads angeht: Das hat man hier als Ersteller eines Threads gottlob nicht in der Hand.

Und off-topic: Der Diskussion um Energie und deren Wende täte es gut, würde sie auf dem sachkundigen Niveau dieses Threads geführt. Komplexe Zusammenhänge sind nun mal nicht einfach. Simplifizierung hilft da nicht wirklich weiter.

j!more (Beitrag #146) schrieb:

In einigen Beiträgen wurde versucht, Dir das Konzept der Tags näher zu bringen, was offensichtlich überhaupt nicht gelungen ist. Das ist bedauerlich, weil da das eigentliche Potenzial von "Computer Audio" liegt, und man dieses Potenzial mit wav a) nicht nutzen und b) später nur mit extrem viel Aufwand und/oder Glück nutzbar machen kann. Weil nicht vorhandene Metadaten eben nicht da sind.

Ich persönlich kann mir - jenseits der Welt physischer Datenträger - ein Leben ohne Tags definitiv auch gar nicht vorstellen, finde es aber andererseits völlig legitim, wenn das jemand für sich anders entscheidet. Wenn jemand beispielsweise seinen Kram einfach nur daheim Streamen möchte, dafür als einzige Metadaten lediglich Albumtitel, Trackinterpret und Tracktitel benötigt und seine Soft- und Hardware diese Informationen problemlos aus den Verzeichnis- und Dateinamen extrahieren kann, kann er durchaus auch erst mal ohne Tags auskommen - und wenn sich seine Bedürfnisse niemals ändern, eben auch bis ans Ende seiner Tage. Für die Nichtverwendung von Tags gibt es drei mögliche Gründe:

1) Man hat keine Ahnung, dass es so etwas überhaupt gibt oder weiß nicht, wozu es überhaupt gut sein soll.

2) Man kennt genau die Möglichkeiten von Tags, hat aber für sich selber entschieden, dass man sie nicht nutzen wird.

3) Man kennt die Möglichkeiten und würde sie auch gerne nutzen, hat aber schlicht nicht die Zeit und/oder Muße, sie auch wirklich vernünftig zu pflegen.

Zumindest die Punkte 2) und 3) finde ich erst mal vollkommen legitim, um auf Tags zu verzichten und die heutige Infrastruktur macht es einem - bei überlegtem Vorgehen - auch durchaus leicht, gewisse Dinge später noch nachzuholen. Wer beispielsweise erst mal nur in WAV rippt und lediglich auf eine halbwegs sinnvolle Verzeichnisstruktur achtet, der kann die Konvertierung in FLAC und das Hinzufügen von Tags auch später noch nachholen, ohne hierfür insgesamt deutlich mehr Zeit zu benötigen als wenn er dies direkt beim Rippen erledigt hätte. Das absolut Einzige was man unter allen Umständen vermeiden sollte, ist doppeltes Rippen oder doppeltes Taggen (inklusive händischer Nachbearbeitung), aber ansonsten kann man sich hier schon gewisse Freiheiten nehmen.

@shaboo: Vollkommen einverstanden. Ich möchte nur gerade in Threads mit wertvoller Information vermeiden, dass Ahnungslosigkeit weiter gegeben und kultiviert wird. Jeder soll sich gerne in seiner Filterblase einrichten, aber es gibt eben doch so etwas wie "best practice", die im Mittelpunkt stehen sollt.

Was die Möglichkeiten des nachträglichen Taggens angeht, bin ich nicht so optimistisch. Ich setze zur Optimierung meiner Metadaten verschiedene Tools ein, darunter auch solche, die Geld kosten. Die Ergebnisse sind oft alles andere als befriedigend. Und aus der Verzeichnisstruktur (die wegen der Mediadaten bei mir nicht relevant aber zwangsläufig dennoch sehr ordentlich ist) lässt sich halt nicht alles wieder herstellen, was beim Rippen anfällt.

Kurz und gut: Auf wav zu setzen ist einfach nicht klug, egal, wie man es nun dreht und wendet. Im Übrigen verweise ich auf meine Signatur.

Für mich trifft zB 2) zu, insb. aufgrund von 3)

Dass ich vor 10 Jahren nicht gleich nach FLAC gerippt habe, lag daran, dass

a) damals viele Player wav abspielen konnten, nicht aber FLAC, und ich nicht jedesmal rückkonvertieren wollte, sondern nur in die Player kopieren
b) ich damals bezweifelt habe, ob sich FLAC überhaupt am Markt hält....

sowohl a) als auch b) ist inzwischen hinfällig oder weniger bedeutend

daher habe ich jetzt bei der Migration auf neue Festplatten alles strukturerhaltend konvertiert und zugleich mit der AC/Cuetools Datenbank abgeglichen (mit dem Resultat, dass keine Ripfehler vorlagen) (etwa 100 CDs können nicht verifiziert werden, weil sie teils nicht bitidentisch sind (alter Audiorekorder), teils zwar bitidentisch sind, aber jeder Track einen anderen Offset hat (neuere Audiorekorder ), einige weniges unhörbare Pressfehler haben und einige mit Cactus DS versaut sind.

PS: Unkomprimiertes FLAC soll laut wiki WAV mit Tagfähigkeit sein. Hat das wirklich dieselbe Audio-Datenstruktur wie WAV?

j!more (Beitrag #148) schrieb:

Was die Möglichkeiten des nachträglichen Taggens angeht, bin ich nicht so optimistisch. Ich setze zur Optimierung meiner Metadaten verschiedene Tools ein, darunter auch solche, die Geld kosten. Die Ergebnisse sind oft alles andere als befriedigend. Und aus der Verzeichnisstruktur (die wegen der Mediadaten bei mir nicht relevant aber zwangsläufig dennoch sehr ordentlich ist) lässt sich halt nicht alles wieder herstellen, was beim Rippen anfällt.

CUE-Ripper holt sich seine Tags aus vielen verschiedenen Quellen, unter anderem von discogs, und die Infos dort sind schon sehr gut, insbesondere, wenn man mittels der EAN bzw. der Katalognummer des Labels darauf achtet, exakt das richtige Release zu verwenden. Ich kontrolliere sie allerdings auch in jedem einzelnen Falle noch einmal und passe das Ganze (minimal) rein synatktisch dem von mir verwendeten Format an. Am aufwendigsten gestaltet sich bei mir dabei das Comment-Tag, wo man sich halt gut überlegen muss, was man da genau in welcher Form an Informationen rein packt. Schließlich will man sich ja auch nicht total mit irrelevanten Metadaten zumüllen. Zudem lasse ich alles weg, was nicht hundertprozentig objektiv ist, wie z.B. das Genre. Nachträgliches Taggen ist Dank CUE-Tools eigentlich auch nicht wirklich ein Problem. Das Aufwendigste ist und bleibt halt das händische Kontrollieren, Modifizieren und Ergänzen.

Schöne Signatur übrigens ...