Mailinglist Archive: opensuse-de (5499 mails)
| < Previous | Next > |
Re: DVD Brenner Software k3b
- From: Al Bogner <suse-linux@xxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 1 Jan 2004 21:41:03 +0100
- Message-id: <200401012119.47803.suse-linux@xxxxxxxxxxxxxxxxxxxxx>
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
> 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
| < Previous | Next > |