Hallo Moritz, bitte lerne, Emails ordentlich zu quoten, siehe dazu http://learn.to/quote/. Bei derartigen Mails mit TOFU, wie Du sie produzierst, sinkt meine Antwortbereitschaft ziemlich drastisch... Moritz Donhauser wrote:

Ich habe nun nochmal probiert k3b selber zu compilieren, jedoch will k3b das ich eine neuere qt version installiere. Als ich das gestern gemacht habe hat mein ganzes linux verrückt gespielt und viele anwendungen gingen nicht mehr ( verständlicherweise).

Natuerlich, die QT-Version muss z.B. zu KDE passen. Ich glaube auch nicht, dass Du zum Compilieren von k3b eine neuere Version von QT brauchst, denn...

Ich bekomme folgenden fehler:

checking for Qt... configure: error: Qt (>= Qt 3.1 (20021021)) (headers and libraries) not found. Please check your installation! For more details about this problem, look at the end of config.log.

...SuSE 8.2 bringt QT 3.1.1 eigentlich mit, und das erfuellt die Bedingung QT >= 3.1. Was Dir fehlt, sind vermutlich die Development-Pakete, die man zum Compilieren eigener Software braucht. Ich wuerde mal ein "rpm -qa | grep qt" machen und schauen, ob da z.B. das qt3-devel Paket installiert ist. Falls nicht, dann nachholen, das evtl. vorhandene Cache-File des ./configure Laufes von k3b loeschen und nochmal probieren. Falls es immer noch nicht geht, dann den Rat von configure befolgen: "For more details about this problem, look at the end of config.log" CU, Thomson

Al Bogner wrote:

Am Dienstag, 30. Dezember 2003 23:10 schrieb Moritz Donhauser:

...

ich habe zu weihnachten einen dvd brenner (plextor px-708) bekommen. Da ich derzeitig suse 8.2 verwende will ich ihn mit diesem betriebsystem nutzen und nicht kurzerhand auf 9.0 umsteigen.

Wozu brauchst du k3b bzw. ein GUI? Bau dir ein simples Kommandozeilenscript und verwende das letzte cdrecord-pro.

Schnickschnack. Wenn er eine GUI moechte, lass ihn eine GUI benutzen, man kann/darf/sollte niemanden zur Kommandozeile zwingen. Wenn ich sehe (und hier auf der Liste miterlebe), was Du fuer Skripte versuchst zu schreiben, die dann am Ende vielleicht doch nicht das machen, was sie sollen (wovon ich aber bei Dir jetzt mal nicht ausgehen moechte, nachdem Du so lange dran rumgedoktert hast), sorry, dann nehme ich lieber gleich k3b, was IMHO ein ganz gutes Programm zum Brennen ist. Kommandozeile ist manchmal vorteilhaft, aber nicht immer, und fuer jemanden, der vielleicht von Windows umsteigt und neu bei Linux ist schon mal gar nicht. Es bedarf Zeit, den Umgang mit der Kommandozeile zu lernen, und wenn man eben zu Beginn gleich mal eine CD gebrannt haben muss, dann ist das wohl nicht der richtige Weg, da dort die Frusterlebnisse meist eindeutig ueberwiegen.

Das gibt es als fertiges Binary und es läuft hier unter 8.2 bestens. Gerade beim Brennen verstehe ich nicht wozu man ein GUI braucht.

Ich kann mit der Maus alle Sachen, die ich brennen moechte, einfach per Drag&Drop ins Fensterchen ziehen. Ooops, jetzt sind es mehr als 700 MB geworden, na, dann nehme ich das halt wieder raus. Eine GUI kann hier sehr wohl Sinn machen...! Diese Haltung, immer _alles_ an der Kommandozeile machen zu wollen, ist IMHO fehl am Platze. Dass es in gewissen Situationen Sinn macht, bestreitet sicher niemand.

Man definiert _1x_ ein paar Scripts (zB Daten, Audio, DVD) mit unterschiedlichen Optionen, definiert einen Ordner, wo per Link die zu brennenden Dateien hineingeschoben werden und los gehts.

Man installiert _1x_ ein Programm (z.B. k3b) und nutzt es, wobei man direkt die Optionen vor dem Brennen waehlen kann, klickt sich seine zu brennenden Daten zusammen und los gehts... Wenn man mit den Features und Optionen, die k3b (oder ein anderes Brennprogramm bietet) zufrieden ist, warum soll man es dann nicht nutzen? Skripte, die "mehr" machen als k3b kann man sich im Laufe der Zeit immer noch selbst zusammenbasteln... Zum Zusammenstellen einer DVD reicht k3b allemal, und uebers (illegale) Klonen von Musik/Film-DVDs moechte ich mich jetzt hier nicht auslassen. CU, Th.

Am Mittwoch, 31. Dezember 2003 10:03 schrieb Thomas Hertweck:

Al Bogner wrote:

...

Am Dienstag, 30. Dezember 2003 23:10 schrieb Moritz Donhauser:

...

ich habe zu weihnachten einen dvd brenner (plextor px-708) bekommen. Da ich derzeitig suse 8.2 verwende will ich ihn mit diesem betriebsystem nutzen und nicht kurzerhand auf 9.0 umsteigen.

Wozu brauchst du k3b bzw. ein GUI? Bau dir ein simples Kommandozeilenscript und verwende das letzte cdrecord-pro.

Schnickschnack. Wenn er eine GUI moechte, lass ihn eine GUI benutzen, man kann/darf/sollte niemanden zur Kommandozeile zwingen.

Da gebe ich dir voll recht. Ich benutze meist auch ein GUI lieber als ein Script. Ich kenne die Wünsche und den Stand der Linux-Kenntnisse des OP nicht. Ich wollte einfach nur mal auf die Alternative Kommandozeile hinweisen und die Optionen nennen, die sich für _mich_ als sinnvoll erwiesen haben. IMO ist es am schwierigsten die Optionen zu finden, die man wirklich braucht, um gute Ergebnisse zu brennen. Ein Freund von mir, ehemals Sysadmin von > 1000 Rechnern brannte aus _Gewohnheit_ auch mit k3b und will nun mein Script verwenden, weil wir beide ähnliche Brennbedürfnisse haben. Beim Brennen konnte _ich_ mich für _meine_ Brennwünsche mit einem GUI noch nie richtig anfreunden, und zwar deshalb, weil ich seit Jahren immer ähnliche Dinge brenne, wobei das Script nach bestimmten Kritieren die zu brennenden Dateien erstellt und ich mir dadurch nicht den Kopf zerbrechen muß, ob ich eine Datei vergessen habe. Das gilt zB besonders für meine Datensicherung, wo ich Kompromisse machen muß, da ich nicht jedesmal alles brenne, aber mir zB keine Gedanken darüber machen will, dass ich ja die neue config-Datei einer weiteren Kernelvariante auch mitsichern möchte. Ich brenne zB auch meine mp3s fürs Auto per Script, so nach dem Motto, heute habe ich eine längere Autofahrt vor und habe dazu zB Lust "Weltmusik" zu hören. Also lieber Computer, sieh in der mysql-DB mal nach, was ich davon habe, such die Dateien zusammen, benenne sie so um, dass mein Autoplayer die ersten 12 Alben über die Stationstasten ansprechen kann, etc. Solche Brennszenarien lassen sich IMO am besten mit einem eigenen Programm umsetzen und da ich meine Shell-Kenntnisse vertiefen wollte, habe ich dafür die bash verwendet und nicht Perl, Python oder was immer. Bei so was merkt man dann schon die Grenzen der Bash, man hat aber dazu gelernt, dass es irgendwie doch geht, wenn auch manchmal nicht sehr elegant. Das wichtigste aber für mich ist, dass es funktioniert. Ich gebe aber auch zu, dass ich mich aufgrund meiner _funktionierenden_, wenn auch manchmal aufgrund der Anfangsfehler etwas holprig formulierten Scripts, nicht so sehr mit k3b, xcdroast, etc. beschäftigt habe. Wie gesagt, entscheidend ist für mich, dass es funktioniert, ob das Brennen aufgrund einer suboptimalen Formulierung 1 oder ein paar Sekunden länger dauert, ist für die Sache egal, aber natürlich lernt man immer gerne was dazu. Für mich habe ich beschlossen, funktionierende Srcripts, wenn auch nicht so optimal formuliert, in Ruhe zu lassen und es bei neuen Scripts besser zu machen.

Wenn ich sehe (und hier auf der Liste miterlebe), was Du fuer Skripte versuchst zu schreiben, die dann am Ende vielleicht doch nicht das machen, was sie sollen (wovon ich aber bei Dir jetzt mal nicht ausgehen moechte, nachdem Du so lange dran rumgedoktert hast), sorry, dann nehme ich lieber gleich k3b, was IMHO ein ganz gutes Programm zum Brennen ist.

Erstens, jeder soll so brennen will, wie es für ihn am besten ist. Das steht völlig außer Diskussion und ich will keinen von einer Kommandozeile bzw. Script überzeugen. Bei Problemen sollte man aber überlegen, wie man persönlich schneller zum Ziel kommt. Ein KDE-Update ist ja auch nicht ganz unproblematisch. Über k3b kann ich mir kein Urteil erlauben, da ich mir nur die Oberfläche angesehen habe.

Kommandozeile ist manchmal vorteilhaft, aber nicht immer, und fuer jemanden, der vielleicht von Windows umsteigt und neu bei Linux ist schon mal gar nicht.

Das hängt immer von den Vorkenntnissen ab. Ich bin vom Mac auf Linux umgestiegen und da war ich nur Klicken gewöhnt. Vi etc. war für mich anfangs Horror, um das ich einen großen Bogen machte. Ich _wollte_ aber Dinge mit Linux realisieren und meine ersten Trvial-Scripts ohne Variablen, einfach Komandozeile nach Kommandozeile schrieb ich ganz schnell, u.a. waren das meine Scripts zum Brennen, die auch Jahre nicht geändert wurden, bis vor ein paar Monaten Bedarf da war, weil mir das Ändern der Scripts für unterschiedliche Rechner schön langsam auf die Nerven ging und seitdem entwickelte sich das Script zu einer Größe von ein paar hundert Zeilen, weil meine 11-jährige Tochter verlangte, dass es immer "DAU-sicherer" wurde. Die brennt übrigens lieber auf der Konsole mit dem Script als mit k3b oder xcdroast.

Es bedarf Zeit, den Umgang mit der Kommandozeile zu lernen, und wenn man eben zu Beginn gleich mal eine CD gebrannt haben muss, dann ist das wohl nicht der richtige Weg, da dort die Frusterlebnisse meist eindeutig ueberwiegen.

Wenn man überhaupt keine Ahnung von der Kommandozeile hat, ja. Der OP sprach aber auch von einem DVD-Brenner und meinen Frust bzgl. DVD-Brennen beginne ich erst seit kurzem los zu werden. Erst mit dem 3. Brennprogramm (cdrecord-pro) klappte das Brennen, dafür aber sofort. Wie man zu "closed source" steht, muß natürlich jeder für sich entscheiden. IMO ist das Brennen von DVD schlimmer als CD brennen in den Anfängen. Mit dem falschen Rohling kann sonst alles richtig sein und man wird vom Brennergebnis enttäuscht sein. Ich habe noch immer nicht den Rohling gefunden, der mit allen DVD-Playern hier läuft und verwende keinen Billig-Schrott. Die FW-Version des Brenners wirkt sich auch ganz entscheidend aus und ältere FW kann mit den verwendeten Rohlingen besser funktionieren als die neuere. Die Gefahr ist groß, dass man dem Brenner oder dem Programm die Schuld gibt, obwohl der Rohling das Problem ist. Ohne Vergleichsmöglichkeiten mit anderer Hardware kann man manchmal nicht feststellen, woran es liegt.

Ich kann mit der Maus alle Sachen, die ich brennen moechte, einfach per Drag&Drop ins Fensterchen ziehen. Ooops, jetzt sind es mehr als 700 MB geworden, na, dann nehme ich das halt wieder raus. Eine GUI kann hier sehr wohl Sinn machen...! Diese Haltung, immer _alles_ an der Kommandozeile machen zu wollen, ist IMHO fehl am Platze. Dass es in gewissen Situationen Sinn macht, bestreitet sicher niemand.

Ja, das ist der Punkt, über den ich auch schon viel nachgedacht habe, wie man das mit einem Script hinbekommen könnte, wenn man alle Links eines Verzeichnisses brennt. Das ist ein klarer Vorteil eines GUIs. Ich helfe mir dadurch, dass ich parallel eine Shell aufmache, und mit "du" überprüfe, ob ich schon zuviel brennen möchte. Diese Brennsituation habe ich aber hier so gut wie nicht. Die Sicherung ist so definiert, dass sie normalerweise auf den Rohling passt. Meine mp3-CDs fürs Auto füllt das Script automatisch auf Maximum. Bei 2 Audio-CDs, die sowieso nur mehr in Ausnahmefällen gebrannt werden, ich habe ja mp3, bestimmt das Script, was von einer 2. CD noch darauf passt und bei VideoDVDs ist die Dateigröße eher kein Problem beim Brennen, da das ja schon beim Authoring berücksichtigt wird. Andere Brennszenarien sind die große Ausnahme. Das mag natürlich bei jedem total unterschiedlich sein. Ich sehe für mich keine weiteren Brennnotwendigkeiten. Fertige-CDs /DVDs kopiere ich normalerweise nicht, sondern verwende die Dateien von der HD und wenn ich schon mal eine Sicherung meiner SuSE-Original-CDs machen will, dann verwende ich im wesentlichen nur #!/bin/bash cdrecord -v driveropts=burnfree -dao -overburn -isosize \ dev=0,0,0 fs=32m /dev/cdrom Wenn man diese 3 Zeilen, falls sie zur Hardware passen, in ein Script steckt, es zB "cdkopie" nennt, dann kann man durch simplen Aufruf bereits CD kopieren. Das sollte auch für einen Anfänger nicht allzu schwer sein.

Man installiert _1x_ ein Programm (z.B. k3b) und nutzt es, wobei man direkt die Optionen vor dem Brennen waehlen kann, klickt sich seine zu brennenden Daten zusammen und los gehts...

Das ist für mich genau der _entscheidende_ Punkt für ein Script, ob man das haben will. Und natürlich jeder wie er will. Ich will mir über die Brennoptionen nicht _jedesmal_ Gedanken machen müssen und dann auf irgendetwas vergessen, speziell weil ich dieses Brennszenario schon länger nicht hatte. Ich will nicht darüber nachdenken müssen, ob ich nun mit Brenner X dao oder raw brennen muß, weil ich CD-Text haben will. Ich will nicht darüber nachdenken müssen, dass ich für mp3 iso-level 1 haben will, aber für die Sicherung der mp3 iso-level 3 (meine mp3s wurden iso-level 3 konform bezeichnet), etc. So weit ich gesehen habe, läßt sich das zum Teil bei k3b aber über Projekte lösen.

Wenn man mit den Features und Optionen, die k3b (oder ein anderes Brennprogramm bietet) zufrieden ist, warum soll man es dann nicht nutzen?

Klar!

Skripte, die "mehr" machen als k3b kann man sich im Laufe der Zeit immer noch selbst zusammenbasteln...

Ich habe ja nur auf die Alternative hingewiesen.

Zum Zusammenstellen einer DVD reicht k3b allemal, und uebers (illegale) Klonen von Musik/Film-DVDs moechte ich mich jetzt hier nicht auslassen.

Ich sehe da auch keinen Zusammenhang zu einem _Brenn_Programm. K3b ist ja aber auch ein GUI zum CDs auslesen und ich weiß nicht, ob man so etwas mit k3b hinbekommen kann: "$CDDA2W" --device $DEVICEPAR --auxdevice $AUXILDEVICE --speed $DEVSPEED --max set-overlap=2 -paranoia -paraopts=retries=64 duration=0 $TRACKS --verbose-level $VERBOSLEVEL --gui --deemphasize --cddb 1 cddbp-server="$CDDBSERVER" cddbp-port="$CDDBPORT" "$CDMATCHCODE".wav Das hat nun nichts mit "illegal" zu tun, sondern mit zerkratzten CDs und der Qualität des CD-ROMs. Vor kurzem las ich, dass "--verbose-level all" ganz entscheidend ist, wie gut die CD ausgelesen werden kann und nicht nur einen Einfluß auf die Ausgabe hat. Ach ja, ich las auch, bei zerkratzten CDs kann ein "cdrecord -setdropts -force driveropts=singlesession" helfen, bevor man cdda2wav startet. Zum Glück habe ich nur ganz wenige CDs, die so zerkratzt sind, dass sie fehlerhaft ausgelesen werden. Leider half alles nichts. Da hilft nur ein Testen mit unterschiedlichen Optionen und manchmal war es dann umsonst. Ich habe nun etwas ausgeholt, aber wenn der OP direkt von Windows kommt, sieht er nun, dass es unter Linux Möglichkeiten gibt, die er vielleicht nicht gleich realisieren kann/will, weiß aber, wenn er mit k3b ansteht, dass da noch viele Dinge beim Brennen möglich sind, an die er bis jetzt nicht gedacht hat. Al

Am Donnerstag, 1. Januar 2004 14:56 schrieb Thomas Hertweck:

Das ist leider ein sehr grosses Problem, es gibt ja auch leider unterschiedlich konkurrierende Standards, das macht die Sache nicht gerade uebersichtlicher. Ich habe hier einen DVD+-R(W) Brenner, aber was ist nun besser? DVD+R oder DVD-R usw., das ist doch alles manchmal recht undurchsichtig.

Bei mir kommt noch dazu, dass DVD+R bis jetzt weniger schlecht funktioniert als DVD-R, normalerweise ist es umgekehrt. Ich hätte da eine Marktlücke, ein Sortiment aus verschiedenen Rohlingen zum Testen. Ich denke mir schön langsam, dass es besser ist den teuren DVD-Player rauszuwerfen, als diverse Rohlinge durchzuprobieren. Das kommt nämlich billiger. Den 49€-Cyberhome bei Amazon gibt es leider nicht mehr, der spielte hier wirklich alles. Leider habe ich den verschenkt.

Ja, siehe oben. Das passt zu dem, was ich schrieb. Fuer automatisierte Vorgaenge sind vermutlich Skripte besser, aber um sich eine CD/DVD zusammenzustellen, da mag die GUI wahrlich Vorteile haben. Das einfache hinzufuegen bzw. herausnehmen von Dateien oder Verzeichnissen empfinde ich da schon deutlich als Vorteil, obwohl ich - nebenbei bemerkt - auch zwei Skripte zum Brennen habe :-) Je nach Situation eben.

Genau. Ich bin wohl zu sehr auf meine Situation fixiert. Da wird _nie_ so kreuz und quer zusammengestellt und deswegen bin ich in diesem Bereich Script-Anhänger.

Das ist auch gut so! Fuer mich klang allerdings ein (Zitat von Dir) "Wozu brauchst du k3b bzw. ein GUI? Bau dir ein simples Kommandozeilenscript und verwende das letzte cdrecord-pro." eher nicht wie ein Alternativvorschlag, sondern wie das Verdammen aller GUIs.

So war es ganz sicher nicht gemeint. Zur Kommandazeile habe ich mich erst langsam und nach langer Zeit durchgerungen, als ich Rechner remote administrieren mußte. Vorher hatte ich mich "geweigert" Standard-Kommandozeilentools zu verwerden. Für einen Mac-User sind die anfangs in der Regel ein Horror.

...

"$CDDA2W" --device $DEVICEPAR --auxdevice $AUXILDEVICE --speed $DEVSPEED --max set-overlap=2 -paranoia -paraopts=retries=64 duration=0 $TRACKS --verbose-level $VERBOSLEVEL --gui --deemphasize --cddb 1 cddbp-server="$CDDBSERVER" cddbp-port="$CDDBPORT" "$CDMATCHCODE".wav

Du kannst auch bei k3b jedem Programm beliebige Optionen mitgeben, solange sie eben Sinn machen. Ich habe jetzt nicht genau nachvollzogen, was Dein Aufruf macht, aber in gewissem (vollem? keine Ahnung) Umfang wird das sicher auch k3b koennen.

Ich erkläre mal schnell für die Allgemeinheit was bei diesem Aufruf passiert. Vielleicht wollte ähnliches schon jemand mal umsetzen, und wußte nur nicht wie. Da gab es zu einem Teil gerade eine Frage in der Multimedia-Liste. "$CDDA2W" - Damit kann ich im Script definieren, welches cdda2wav verwendet wird, bzw. welches verwendet wird, wenn unterschiedliche Versionen vorhanden sind. --device $DEVICEPAR - ist klar, zB 0,0,0 (läßt sich über cdrecord -scanbus abfragen, was für das CD-ROM bzw. den Brenner zu verwenden ist) --auxdevice $AUXILDEVICE Das ist etwas kniffelig. Details man cdda2wav. Bei echten SCSI-Geräten ist sr zu verwenden, bei IDE-SCSI gleich wie $DEVICEPAR. Das wird benötigt für CD-Extra und schadet nach meiner Erfahrung nicht, wenn man es grundsätzlich angibt. --speed $DEVSPEED hier verwende ich 0, d.h. maximal. Für schlechte CDs kann man das Laufwerk bremsen. Normalerweise bremst der Paranoia-Mode das Laufwerk automatisch. Vergleiche dazu cdrecord -prcap. Dadurch wurde mir erst klar, warum mein Brenner nur mit maximaler Geschwindigkeit brennen kann. Man kann da also nicht beliebige Werte einsetzen. --max set-overlap=2 Nicht jedes Laufwerk ist jitterfrei. Daher wird überlappend ausgelesen. IMO bremst das auch bei jitterfreien Laufwerken nicht wesentlich. -paranoia liest "paranoid" aus, im Zweifelsfall also vorsichtiger und langsamer. Empfiehlt sich wieder bei Problem-CDs -paraopts=retries=64 Gibt es bei wiederholtem Auslesen einen Fehler, so wird maximal 64x versucht, ein identes Auslesergebnis zu erzielen. -d duration --duration Das habe ich mir mal irgendwo abgeschaut, weiß aber nich mehr genau, warum ich mich dafür entschieden haben (sets recording time in seconds or frames. Frames (sectors) are indicated by a 'f' suffix (like 75f for 75 sectors). 0 sets the time for whole track.) $TRACKS ist fast selbsterklärend, bei teilweisem Auslesen, aber kniffelig. zB TRACKS="--alltracks" zB TRACKS="--track 1" zB TRACKS="-B --track 2+5" Man beachte das -B (= --bulk --alltracks) und das "+" für einen _Bereich_. Aufgrund dieser Konstruktion kann man die Tracks 2-5 mit -B in 4 verschiedene Dateien schreiben und ohne -B in _1_ Datei. --verbose-level $VERBOSLEVEL Hier habe ich ja schon erwähnt, dass die Auslesequalität mit "all" besser wird. --gui macht die Ausgabe lesbarer. Mein Script mit ein paar sed-Befehlen kann die CD-Text-Ausgabe der _einzelnen_ Tracks in eine _einzelne_ Datei so zusammenfassen, dass 1 csv-Datei entsteht, die dann zB in eine Datenbank importiert werden kann. Aufgrund der Struktur der CDDB, habe ich mich dann aber entschlossen, das nicht zu verwenden. Es entstehen dabei zuviele problematische Einträge, die manuell korrigiert werden müßten und das ist wahrscheinlich mehr Arbeit. Die Programmierung meines GUI-DB-Frontends wartet noch :-) Eventuell überlege ich mir mal, das vielleicht mit scribus zu verbinden. Da ich aber so gut wie keine Audio-CDs brenne, ist das eher ein Szenario um mich mit Scribus auseinanderzusetzen. --deemphasize Damit wird bei Verwendung dieser (alten) Aufnahmetechnik, der Frequenzgang entzerrt. --cddb 1 verwendet den 1. gefundenen Eintrag in der CDDB. 0 wäre interaktiv bei mehreren Einträgen cddbp-server="$CDDBSERVER" cddbp-port="$CDDBPORT" sollte klar sein. CDDBSERVER="freedb.freedb.org" CDDBPORT="8880" Ich freue mich schon, wenn da mal localhost oder so steht. Vielleicht hat wer Lust mir dazu ein paar Tips zu geben. Es gibt ja mehrere Möglichkeiten das zu realisieren. "$CDMATCHCODE" bezeichnet die wav-Dateien. Hier habe ich eine ausgeklügelte Bezeichnung, sodass in Verbindung mit der mysql-DB die Parameter zum Encodieren mit mp3 bestimmt werden. Diese Scripte sind nach Jahren so entstanden, dass immer wieder etwas dazu gebaut wurde und daher gibt es hier manche Konstrukte, die ich aus heutiger Sicht auch schrecklich finde. Manche Konzepte stammen ja noch aus meiner Mac-Zeit und die Portierung auf ein anderes OS war ein ziemlicher Kompromiß. Es komplett neu zu machen, freut mich aber gar nicht bzw. es fehlt mir auch die Zeit dazu und dann gibt es eben "Würgarounds", aber funktionieren tut es dann. Abschließend noch ein Disclaimer an alle die schlechtes denken. Ich lese nur CDs aus, die mir auch wirklich gehören und habe noch nie mp3 getauscht. Mp3 finde ich nur dann sinnvoll, wenn optimal encodiert wird und das erreicht man nur durch obiges "paranoides Auslesen" und entsprecheder Encodierungs-Parameter, worüber ich nun nicht weiter schreibe, denn das war vor den "presets" auch eine "halbe" Wissenschaft. Al