Da aber die Musikstücke recht kurz sind, wird das jeweilige Neupositionieren beim schnellen lesen die Datenrate drücken.
Eigentlich nicht, denn die Spur einer CD führt spiralförmig von innen nach außen. In der richtigen Reihenfolge gerippt sollte da keinerlei Positionierung erfolgen.
RaspiBlaster: Gerät zum Rippen von CDs missbraucht oder warum ist ein RPi bisweilen schneller als ein x86-Laptop?? Schau mal ob du hier fündig wirst!
Auführungen zu meinem "Weltbild" über die CD-Technologie
Die Kompressionsrate würde ich jetzt nicht unbedingt an ein Lied fest machen. Ein Durchschnittswert könnte auch bei 60-65% liegen. Es kommt wohl auf die "Qualität" der Musiksammlung an.
Deine "Rip" Zeiten vom DVD/Bluray finde ich recht hoch. [...] Die sollte eigentlich nur begrenzt werden durch die Lesegeschwindigkeit des Laufwerks und der Schreibgeschwindigkeit des Speichermediums. Ich wäre von unter 4 min. pro CD (700MB) ausgegangen. Bei 44x eher unter 2 min..
Bezüglich der Kompressionsrate von FLAC ein paar Links:
de.wikipedia.org/wiki/Free_Lossless_Audio_Codec#Kompression
wiki.hydrogenaud.io/index.php?title=Lossless_comparison#Comparison_Table Hier wird eine Kompression bis hinunter zu 57% genannt
wiki.ubuntuusers.de/FLAC/ Hier wird darauf hingewiesen, dass die Kompressionsstärke mit der Musikart schwanken kann, Zitat:
"Der Platzgewinn hängt zudem stark von der Art des jeweiligen Audiomaterials ab. So kann beispielsweise ruhige, elektronische Musik zumeist wesentlich besser komprimiert werden als laute Rockmusik."
Wie bei jeder Datenkompression spielen die Entropie und Redundanz der Quelldaten eine große Rolle, wie stark die Kompression letztendlich ausfällt. Für klassische Musik dürfte die Kompression noch geringer ausfallen, während man Roland Kaiser (dees is der, der wo vom vegln a so singt, daß 's de oidn Weiba aa g'foid) sinnvollerweise bis hinunter auf 0% komprimieren kann, siehe obige Beiträge in diesem Thread von hyle und STF 
Die ist praktisch aber u.a. abhängig von der Fehlerkorrektur des Laufwerks und natürlich dem Ausgangsmaterial. Audio-CDs (cdda) sind nicht vergleichbar mit Daten-CDs, https://www.xiph.org/paranoia/faq.html#play
Da hatte ich eine Vermutung, die mit dem Link zu CDparanoia von llutz bestätigt wird: Je nach Aufwand bei der Fehlerkorrektur (resultiert in wiederholtem Lesen) sinkt die Nettodatenrate beim Einlesen der Audiodaten.
Dass neue Laufwerke speziell hinsichtlich CDDA nicht zwingend besser sein müssen als welche, die bereits 10 oder 20 Jahre auf dem Buckel haben, leuchtet ein. Die primäre Anwendung von CD-ROM-Laufwerken liegt im Datenmanagement und (gerade heutzutage) weniger in der Audiowiedergabe. Zudem spielen Produktionskosten und (vor allem im Consumerbereich) billige Preise eine größere Rolle als das technisch Möglichste (über Mehraufwand = höherer Preis) herauszuholen.
Ähmm, beim Abspielen läuft jedes noch so schnelle CD-Laufwerk mit der Geschwindigkeit 1-fach.
Das 44-fach ist für das einlesen der digitalen Daten, also auch das digitale Auslesen der CD.
Da aber die Musikstücke recht kurz sind, wird das jeweilige Neupositionieren beim schnellen lesen die Datenrate drücken.
Das mit der einfachen Geschwindigkeit unterschreibe ich pauschal mal so nicht:
Das Laufwerk liest schneller, um "Luft" für eine Fehlerkorrektur zu haben. Am Raspiblaster stoppt das Laufwerk bisweilen sogar. Mit dem mplayer (Ein Videoplayer, der für Audioausgabe nicht optimiert ist) lief das Laufwerk ursprünglich relativ laut mit hohen Umdrehungszahlen und dennoch kam es zu Aussetzern. Erst mit audacious oder alsaplayer (letzterer ermöglicht die Wiedergabe mit bis zu 400% Geschwindigkeit ohne Drehzahlanstieg des Laufwerks) kehrte hier Ruhe ein. Aber auch da dürfte 2fach oder 4fach oder 8fach im Spiel sein...
Der Hinweis des Programmierers von CDparanoia im Link von llutz spricht eigentlich Bände:
"Note that CD 'playback speed' is an excellent example of advertisers making numbers lie for them. A 36x cdrom is generally not spinning at 36x a normal drive's speed. As a 1x drive is adjusting velocity depending on the access's distance from the hub, a 36x drive is probably using a constant angular velocity across the whole surface such that it gets 36x max at the edge. Thus it's actually spinning slower, assuming the '36x' isn't a complete lie, as it is on some drives."
Die Neupositionierung kann schon eine Rolle spielen, aber eher glaube ich, dass beim Einlesen der Audiodaten als Binärdaten ein CD-ROM-Laufwerk eine feste Datenrate und/oder Drehzahl hat. Damals am Toshiba-Laptop unter Windows mit dem Audiograbber V1.8.3 konnte ich beobachten, wie bei konstanter Drehzahl die Netto-Lesegeschwindigkeit am Beginn (innen auf der CD) bei 4,x-fach war und zu den höheren Titeln bis auf 7-8-fach anstieg. Da kommen einfach wegen des größeren Scheibendurchmessers die Bits schneller daher 
Sorry für meine einfache Sicht auf diese relativ komplexen Dinge, aber mit solchen Erklärungen verstehe sogar ich es und meine Kinder
Jedenfalls deckt sich diese alte Erfahrung vom audiograbber mit den gemessenen Zeiten meines abcde-Benchmarks.
Das mit der einfachen Geschwindigkeit unterschreibe ich pauschal mal so nicht:
Das Laufwerk liest schneller, um "Luft" für eine Fehlerkorrektur zu haben. Am Raspiblaster stoppt das Laufwerk bisweilen sogar. Mit dem mplayer (Ein Videoplayer, der für Audioausgabe nicht optimiert ist) lief das Laufwerk ursprünglich relativ laut mit hohen Umdrehungszahlen und dennoch kam es zu Aussetzern. Erst mit audacious oder alsaplayer (letzterer ermöglicht die Wiedergabe mit bis zu 400% Geschwindigkeit ohne Drehzahlanstieg des Laufwerks) kehrte hier Ruhe ein. Aber auch da dürfte 2fach oder 4fach oder 8fach im Spiel sein...
Wenn das CD-laufwerk genutzt wird, um mit einem Player die auf dem Laufwerk befindenden CDDA-'Dateien' abzuspielen, dann läuft es normalerweise mit 1-facher Geschwindigkeit.
Wenn MPlayer das anders macht, dann weil das Programm wohl die Dateien als Daten liest und dann verwurstet.
Aber genau dann passiert das, was ja STF in seinem auf meinem Beitrag bestritten hat.
Das Laufwerk hält an (dreht ohne Positionierung des Lasers) und muss erst wieder die richtige Position für das nächste Stück finden, was Zeit dauert.
Man könnte das reduzieren, wenn man einen ausreichend großen Buffer im Speicher erstellt, und die komplette CD dort hinein lädt.
Dann wären aller höchstens noch Leseversuche bei Lesefehlern nötig. Da einige Programm bei Lesefehlern auch die Geschwindigkeit vermindern und diesen Abschnitt mehrfach lesen, reduziert sich die Lesegeschwindigkeit nochmals.
Dabei sind die Programme im Vorteil, die so schnell, oder langsam, lesen, dass sie weniger Lesefehler haben.
Denn sie sparen sich das wiederholte Neupositionieren.
Aber genau dann passiert das, was ja STF in seinem auf meinem Beitrag bestritten hat.
...Spur einer CD führt spiralförmig von innen nach außen. In der richtigen Reihenfolge gerippt...
Oh nein, es ging ums Rippen, was ich ohne den "einfache Geschwindigkeit Paranoid Modus mit mehrfacher Kontrolle der gelesenen Daten" laufen lasse. Seit jeher nutze ich dazu mit für mich optimalen Ergebnissen das Programm Exact Audio Copy (EAC) unter Windows, welches mein DVD Laufwerk erkennt und die Einstellungen zum Rippen selbst gewählt hat. Zwischen den einzelnen Titeln sind keine Neupositionierungen des Laufwerks zu hören. Über die Geschwindigkeit kann ich nichts sagen, ich guck da nie zu.
Grüße, STF
Details habe ich in meine Anleitung für den Raspiblaster auf github eingearbeitet. Kapitel 4 beschreibt die Installation und Anwendung von abcde auf einem RPi.
Danke dem Ideengeber. Ich hab dass mal auf einer RPi-Jukebox-RFID umgesetzt um schnell und ohne Interaktion die alten Hörspiele im neuen Format via RFID abspielbar zu machen: [Projekt] jukebox4kids (Jukebox für Kinder)
Nachtrag zur Kompressionsrate bei flac:
Dieser Tage habe ich mal wieder ein paar CDs geflact, weil ich dringend welche für die Rock-Weihnachtsfeier(
) nächsten Freitag im Betrieb von einem guten Kumpel brauche. Da arbeite ich jetzt parallel am Laptop und am furchtbar schnellen Raspiblaster:
Meist schaffe ich Kompressionsraten (bei flac-Kompressionsstufe 8 ) zwischen 60% und 70%. Auf der CD Interpret: Body Count / Album: Body Count [Anzeige] befinden sich auch teilweise Titel bestehend aus Sprechgesang mit wenig instrumentaler Akustik. Dort erreicht man dann eine Kompression von 57,9% (Ice-T / Freedom Of Speech - spoken words by Jello Biafra). Wie bereits in Beitrag #22 gesagt, hängt es von der Art/Entropie("Durcheinander") der Quellmusikdaten ab: Je akustisch komplexer (nicht unbedingt künstlerisch komplexer 
) ein Musikstück ist, um so geringer fällt die resultierende Kompression aus.
EDIT:
...und beim Soundtrack von Mel Gibson's Braveheart erreiche ich gerade folgende Komressionen:
Track 12: 40,5%
Track 13: 45,8%
Track 14: 48,0%
Track 15: 53,5%
Track 16: 34,8%
Track 17: 40,7%
Track 18: 42,0%
Die Musikstücke (großteils nur Hintermalung des Films mit wenig Entropie) geben diese Kompression her
noch eine Edith:
Bei The Who: Then and Now! [Anzeige] sind es wieder so um die 70%:
Track 14: 73,3%
Track 15: 67,2%
Track 16: 71,9%
Track 17: 68,2%
Track 18: 67,0%
Track 19: 65,6%
Track 20: 66,2%
Fazit: Du musst mehr Filmmusik komprimieren. Zumindest relativiert sich nun der anfängliche Wert von 80%.
Also wenn pro Zeiteinheit bei gleichbleibender Bitrate ein Wert (2 Bytes?) gespeichert werden, wüsste ich nicht wie die Amplitude (Lautstärke) Einfluss auf die Kompressionsrate haben sollte. Aber vielleicht macht FLAC da irgendwas inteligentes. Ich könnte mir vorstellen, das Heutzutage beim Mastern (Abmischen) mehr Kompressor benutzt wird als Früher. Was dann geringere Kompressionsraten bewirkt.
Kannst du ja mal testen, indem du ein Musikstück normal mit FLAC komprimierst und dann nochmal, aber mit z.B. 50% geringere Lautstärke.
Werden da einzlene Flacs produziert, oder eine riesen flac Datei pro cd mit Metadata.?
Werden da einzlene Flacs produziert, oder eine riesen flac Datei pro cd mit Metadata.?
Gegenfrage. Wie würdest Du das als DJ beim rippen alter CDs handhaben?
Ich hab mal vor langer Zeit für Ubuntu eine udev rule ""gefunden"",
die vollautomatsch beim Einlegen einer Audio-CD rippt.
Das geht alles, was man braucht ist Internet um die CD-Tittel und die Namen der Stücke zu bekommen.
Mit cdparanoia wird die CD ausgelen (es heißt nicht umsonst Paranoia).
Heraus kommt eine *.bin Datei mit ungefahr 600 MB.
Dies bin Datei wird mittels flac umgewandelt ins flac format.
Das eigentliche highlight ist das dieses Flac Metadaten hat.
Das war noch vor der Zeit als Android in meinem Focus war.
Es gibt einige Android Player die tadellos einzelne Music-Stücke aus der "komplett-CD-Flac Datei" anfahren kann. VLC nicht ein anderer, weiß ich jetzt nicht.
Ist aber ein schlamppiges Spagetti Script :-), dass von der udev rule angestoßen wird.
Ahso ich betreibe den Raspberry nicht mit einer Sd-card sondern über USB3 und SSD-Festplatte.
Werden da einzlene Flacs produziert, oder eine riesen flac Datei pro cd mit Metadata.?
Bei Internetzugang zu FreeDB oder musicbrainz wird die CD in den Datenbanken gesucht und die Titelliste zum Editieren bereitgestellt. Es wird ein Verzeichnis mit dem Namen des Interpreten angelegt. Dort ein Unterverzeichnis mit dem Namen des Albums. Darin werden einzelne EDIT: mit den entsprechenden Metadaten versehene FLAC-Dateien erstellt und eine *.m3u-Datei mit allen Liedern der CD abgelegt, die in vielen Audioplayern dann als Playlist geladen werden kann.
Manchmal findet abcde sogar automatisch Coverbilder, leider oft in schlechter Qualität. Da findet man im Browser mit Duckduckgo/Bildersuche wesentlich bessere Ergebnisse.
zeigt aber dennoch, dass ein RPi bei Verwendung vernünftiger Peripherie durchaus konkurrenzfähig ist.
Details habe ich in meine Anleitung für den Raspiblaster auf github eingearbeitet.
echt jetzt?
immer mit demselben Laufwerk?
Wo hat der PI eine p-ata Schnittstelle oder war es schon ein SATA DVD/CD Laufwerk?
So ganz blicke ich nicht die Ironie 
jar:
Also der erste Raspiblaster hat ein reines USB-Laufwerk, den DVD-Brenner LG GP50NW40. Dieses Laufwerk ist von der Geschwindigkeit her beim Rippen einer Audio-CD (und nur darum geht's in diesem Thread) durchaus behäbig. Dieses Laufwerk kann man am RPi relativ leicht anschließen, da es nur einen USB-Anschluss hat.
Beim zweiten Raspiblaster mit dem S-ATA-Laufwerk LG BH16NS55 benötigt man für den Anschluss am RPi natürlich noch einen USB/S-ATA-Wandler, der Spannungseingänge für 5V und 12V zur Verfügung stellt. Da gibt's nämlich welche für 2,5"-SSDs. die nur 5V-Eingangsspannung haben. Ich habe da einen für USB3.0 eingebaut (weil es keinen anderen mehr gab). Auf jeden Fall ist dieses Laufwerk relativ schnell beim Rippen von Audio-CDs über cdparanoia bzw. abcde.
Und das hat natürlich nichts mit dem RPi zu tun, der ist daran unschuldig 
, dass das Rippen von Audio-CDs auf diesem Laufwerk so schnell läuft. Ich habe es halt hier im Forum beschrieben und wurde von einigen Kapazitäten des Forums wegen meiner angeblich irreführenden(?) Überschrift gemaßregelt. Daraufhin sah ich mich veranlasst, dies in diesem Thread gleich zu Beginn eindeutig klarzustellen und als "Ironie" zu kennzeichnen.
OK,
ich bin gerade etwas angepisst, hatte einen Sharkoon SATA2USB3 Adapter gekauft von Amazon, dummerweise kann der nur Platten bis 2TB und weil eben nicht genau der Hinweis war das er größere Platten verarbeitet habe ich den gleich in den Elektronik-Schrott versenkt, wegen 30,-€ wollte ich mir den Stress und die Diskusionen mit Amazon nicht antun.
Dann kaufte ich einen SATA2USB3 Adapter über Ebay der mit bis zu 12TB warb, der macht es aber auch nicht, dann endlose Diskusion mit dem Händler, das liegt nun bei EBAY Käuferschutz.
Mein logilink Adapter kann >2TB, nur wollte ich einen 2ten zum kopieren.
https://www.ebay.de/itm/Ugreen-Ext…8.c100290.m3507
"Supports simultaneous connection of 2.5" 3.5" SATA I II III hard drive SSD HDD up to 12 TB and is compatible with all popular operation systems like Windows XP Vista 7 8 8.1 10 , Mac OS 10.4 to 10.13, Linux, Chrome"
Don’t have an account yet? Register yourself now and be a part of our community!
