www.fabiankeil.de/freebsd/iriver-340h.html
Diese Seite ist die Ergänzung zu meinen Erfahrungen mit dem iRiver H340. Das Kodieren in passende Formate und das anschließende Hochladen auf den Player wurde nicht näher erläutert, dies sei hiermit nachgeholt.
Ich nutze den Player mit FreeBSD, die Beschreibungen sollten aber unter GNU/Linux und anderen Unix-Derivaten ähnlich funktionieren. Abweichungen wird es hauptsächlich bei der Installation der Software und beim Mounten geben – ausprobiert habe ich es nicht.
Von den vom iRiver H340 beherrschten Codecs ist Ogg Vorbis der sympathischste. Ogg Vorbis gilt nicht nur als MP3 überlegen, sondern ist auch frei verfügbar.
Für die MP3-Erzeugung steht zwar mit lame ein kostenloser Encoder bereit, der auch klanglich gute Ergebnisse bringt, MP3 ist jedoch patentbefleckt, zur kommerziellen Verbreitung sind Lizenzgebühren zu zahlen.
Ogg Vorbis gilt noch als patentfrei, im Zeitalter der Trivialpatente natürlich eine recht optimistische Annahme.
Noch ist die Verbreitung lizenzfrei möglich und selbst wenn MP3 momentan weiter verbreitet ist, lohnt es jetzt schon, Audio durchgehend nach Ogg Vorbis zu transkodieren, und MP3 nur noch bei bereits vorhandenen Dateien zu nutzen. Der H340 bietet dazu die Gelegenheit.
Der Port /usr/ports/audio/vorbis-tools beinhaltet alles Nötige, um aus Wave-Dateien Ogg-Vorbis-Dateien zu erzeugen. Man kann auch den umgekehrten Weg gehen, oder Ogg Vorbis einfach nur abspielen.
Der Port installiert oggenc
und oggdec
zum En- und Decodieren, den Ogg-Vorbis-Player ogg123
sowie ogginfo
um Metadaten wie Name, Album und Titel anzuzeigen, falls gespeichert.
Bei einer ordentlich erzeugten Datei liefert ogginfo
etwas wie:
fk@r51 ~/vorbis/Janis Joplin/The Very Best Of $ogginfo "01 - Me And Bobby McGee.ogg" Processing file "01 - Me And Bobby McGee.ogg"... New logical stream (#1, serial: 1d7b1002): type vorbis Vorbis headers parsed for stream 1, information follows... Version: 0 Vendor: Xiph.Org libVorbis I 20040629 Channels: 2 Rate: 44100 Nominal bitrate: 192.000000 kb/s Upper bitrate not set Lower bitrate not set User comments section follows... discid=b40b1b0c title=Me And Bobby McGee artist=Janis Joplin genre=Blues date=1983 album=The Very Best Of tracknumber=01 Vorbis stream 1: Total data length: 5988656 bytes Playback length: 4m:32s Average bitrate: 176.076523 kbps Logical stream 1 ended
discid
ist kein standardisierter Tag – im Ogg-Jargon Kommentar
–
mit oggenc
können nach Belieben eigene Kommentare kreiert werden.
Die wichtigeren Daten bekommt man auch beim Abspielen angezeigt:
fk@r51 ~/vorbis/Janis Joplin/The Very Best Of $ogg123 "05 - Piece Of My Heart.ogg" Audio Device: OSS audio driver output Playing: 05 - Piece Of My Heart.ogg Ogg Vorbis stream: 2 channel, 44100 Hz Discid: b40b1b0c Title: Piece Of My Heart Artist: Janis Joplin Genre: Blues Date: 1983 Album: The Very Best Of Track number: 05 Done.
Auch oggdec
kann man einfach die Quelldatei als Argument übergeben
und auf das Ergebnis warten, es werden dann allerdings keine Kommentare erzeugt.
Um eine korrekt kommentierte Ogg-Vorbis-Datei zu erstellen, ist ein Aufruf wie der folgende nötig:
oggenc --artist "$interpret" --title "$titel" --album "$album" --genre "$genre" --date "$date" --tracknum $tracknummer -c "discid=$discid" -q 6 --names="%a/%l/%n - %t.ogg" $wavedatei
Bis zum -c
-Parameter ist der Aufruf selbsterklärend: es werden die Standard-Kommentare gesetzt.
Mit dem -c
-Parameter wird ein beliebiger Kommentar erzeugt, deren Anzahl ist unbegrenzt,
mehrere eigene Kommentare erfordern aber mehrere -c
-Parameter.
Mit -q 6
wird die Qualitätsstufe festgelegt. Vorbis hat davon zehn, sechs ist
laut Dokumentation für von CDs stammende Inhalte
passend. Momentan entspricht -q 6
einer variablen Bitrate von 192
kb/s, die Idee ist allerdings, durch weitere Verbesserungen
am Codec bei gleicher Qualität weniger Bits zu verbrauchen. Durch die Angabe der Qualitätsstufe
erhält man zukünftig eventuell kleinere Dateien, ohne die Kommandozeile verändern zu müssen.
--names="%a/%l/%n - %t.ogg"
gibt an wie die Ausgangsdatei heißen soll und in welches
Verzeichnis sie gepackt wird. Die Platzhalter entsprechen der Reihe nach Interpret, Albumname, Liednummer
und Liedname.
Ursprünglich hatte ich die Formatierung --names="%a - %l/%n - %t.ogg"
benutzt. Damit verliert
man auf dem iRiver H340 aber schnell die Übersicht, die Navigation wird zum Krampf, weil das Verzeichnis
%a - %l
mit hoher Wahrscheinlichkeit nicht vollständig auf das Display passt. Mehrere
Alben vom gleichen Interpreten lassen sich so auf den ersten Blick nicht unterscheiden, man muss
die Verzeichnisse einzeln markieren und warten, bis der H340 den hinteren Teil des Namens einblendet.
Das letzte Argument gibt die Quelldatei an.
cdda2wav
cdda2wav
ist Teil der cdrtools und unter FreeBSD im Port
/usr/ports/sysutils/cdrtools-devel
zu finden. Um auch ATAPI-Laufwerke ansprechen zu können, muss device atapicam
im Kernel
vorhanden, oder (seit FreeBSD 6.0) atapicam als Modul geladen sein.
Zusätzlich ergibt es Sinn, den DMA-Modus auch für optische Laufwerke zu aktivieren.
Dafür sorgt die Zeile hw.ata.atapi_dma="1"
in /boot/loader.conf
.
Ein ordentlicher cdda2wav
-Aufruf ist
cdda2wav -B dev=$dev -paranoia --cddb 0
.
Damit wird die ganze Audio-CD (-B
) vom Laufwerk
$dev
gerippt, wobei mit -paranoia
besonders auf die Qualität geachtet wird.
Die Werte für $dev
werden genauso ermittelt, wie in
C2-Scans mit readcd beschrieben.
Durch Angabe von --cddb 0
wird die FreeDB interaktiv abgefragt, eine
Datenbank die Informationen wie Interpret, Albumname, Liedname und Aufnahmedatum für eine Großzahl
von Audio-CDs vorrätig hält. Oft kommt es vor, dass eine
CD mehrfach erfasst ist, in diesem Fall lässt cdda2wav
den Benutzer wählen, welcher Datensatz verwendet werden soll.
Die aus der FreeDB gewonnenen Daten speichert cdda2wav
–
zusammen mit weiteren Informationen über die CD – in
verschiedenen Textdateien. Aus denen werden sie beispielsweise von cdrecord
gelesen,
wenn man die gerippte CD brennen möchte.
Natürlich können die Dateien auch von Hand geöffnet sowie gelesen werden, um anschließend einen
passenden oggenc
-Aufruf zu basteln. Ebenso natürlich ist das unnötige Arbeit,
die man automatisieren kann.
cdda2wav
und oggenc
Dazu benutze ich das Skript wav2ogg.sh
, es basiert auf
Frederick Pages grabit.sh
und kann unter BSD-Lizenz benutzt werden:
#!/bin/sh #Encodes wave files created with cdda2wav into ogg vorbis. # #Based on the last part of Frederick Page's grabit.sh #http://www.dchlb.de/cdrecord/cdrecord_scripte.html#grabit # #Modifications made by Fabian Keil (fk@fabiankeil.de) # #There is almost no error checking done. dev="2,0,0" temp=temp$$ mkdir $temp cd $temp cdda2wav -B dev=$dev -paranoia --cddb 0 cdrecord dev=$dev -eject if test -e audio.cddb; then genre=`grep "^DGENRE=" audio.cddb | sed -e "s/^.*=//" |\ sed -e "s/^'//" -e "s/'$//" -e "s/\//-/g" -e 's/[\:*?"<>|]//g'` date=`grep "^DYEAR=" audio.cddb | sed -e "s/^.*=//" |\ sed -e "s/^'//" -e "s/'$//" -e "s/\//-/g" -e 's/[\:*?"<>|]//g'` discid=`grep "^DISCID=" audio.cddb | sed -e "s/^.*=//" |\ sed -e "s/^'//" -e "s/'$//" -e "s/\//-/g" -e 's/[\:*?"<>|]//g'` albumperformer=`grep "^Albumperformer=" "audio_01.inf" | cut -f 2 | \ sed -e "s/^'//" -e "s/'$//" -e "s/\//-/g" -e 's/[\:*?"<>|]//g'` for infdatei in audio*.inf; do datei=`basename "$infdatei" .inf`.wav if test -e "$infdatei"; then interpret=`grep "^Performer=" "$infdatei" | cut -f 2 | \ sed -e "s/^'//" -e "s/'$//" -e "s/\//-/g" -e 's/[\:*?"<>|]//g'` titel=`grep "^Tracktitle=" "$infdatei" | cut -f 2 | \ sed -e "s/^'//" -e "s/'$//" -e "s/\//-/g" -e 's/[\:*?"<>|]//g'` album=`grep "^Albumtitle=" "$infdatei" | cut -f 2 | \ sed -e "s/^'//" -e "s/'$//" -e "s/\//-/g" -e 's/[\:*?"<>|]//g'` trackno=`grep "^Tracknumber=" "$infdatei" | cut -f 2` if test $trackno -lt 10; then trackno="0"$trackno fi oggfilename="$interpret-$tracknum-$title" oggenc --artist "$interpret"\ --title "$titel"\ --album "$album"\ --genre "$genre"\ --date "$date"\ --tracknum $trackno\ -q 6\ -c "discid=$discid"\ --names="../$albumperformer/%l/%n - %t.ogg"\ $datei rm $datei fi done fi
Eigentlich müsste es cdda2ogg
heißen, aber der cdda2wav
-Aufruf
kam erst später rein. Das Skript ist funktionsarm und fängt nur wenige Fehler ab,
für mich ist es jedoch ausreichend und es hat sich hundertfach bewährt.
Ist die eingelegte CD bereits in der FreeDB
erfasst, erstellt wav2ogg.sh
ein temporäres Verzeichnis in das die
CD mit cdda2wav
gerippt wird.
oggenc
encodiert die Lieder mit Kommentaren und speichert
sie an passender Stelle. Die von cdda2wav
erzeugten Dateien werden anschließend gelöscht,
das temporäre Verzeichnis verschwindet ebenfalls.
Kennt FreeDB die CD nicht und ist auch kein
CD-Text vorhanden, hilft wav2ogg.sh
nicht weiter.
Ogg-Vorbis-Dateien ohne passende Kommentare erzeugen schlechtes Karma, wav2ogg.sh
bricht den Vorgang daher ab, bevor weiterer Schaden entsteht.
Grip
Auch wenn in der FreeDB eine beachtliche Zahl CDs erfasst sind, stößt man von Zeit zu Zeit auf ein Album, bei dem das nicht der Fall ist.
Man könnte die CD dennoch mit cdda2wav
rippen und die erzeugten Textdateien mit den Meta-Informationen von Hand erweitern.
Dazu müsste jedoch für jedes Lied eine Datei editiert werden – etwas umständlich.
Schneller geht es durch Verwendung von Grip
, einem auf GTK basierendem Frontend
für verschiedene Kommandozeilenprogramme, unter anderen auch cdda2wav
und
oggenc
. In Grip
können der FreeDB unbekannte
CDs einigermaßen komfortabel betextet werden,
die Daten kann man anschließend an die FreeDB übermitteln.
Grip
ist in den Ports unter /usr/ports/audio/grip
zu finden. Bei der Installation wird abgefragt, welche Programme verwendet werden sollen,
cdparanoia
ist vorausgewählt. cdda2wav
enthält seit einigen Jahren
die cdparanoia
-Routinen, ist funktionsreicher und damit die bessere Wahl.
Beim ersten Grip
-Start werden Voreinstellungen geladen, die nicht meinem
Geschmack entsprechen. Die Einstellung werden der Konfigurationsdatei ~/.grip
entnommen, geändert habe ich folgende Werte:
ripexename /usr/local/bin/cdda2wav ripcmdline -paranoia -D %C -x -H -t %t -O wav %w mp3exename /usr/local/bin/oggenc mp3cmdline -o %m -a %a -l %d -t %n -q 6 %w -N %t -G %g -d %y -c "discid=%i" ripfileformat ~/iriver-spiegel/vorbis/%*A/%*d/%t - %*n.wav mp3fileformat ~/iriver-spiegel/vorbis/%*A/%*d/%t - %*n.%x
Grip
verhält sich nun in etwa wie wav2ogg.sh
, vor dem Rippen können
jedoch die Titel eingeben werden.
Grip
zeigt die Ausgaben der verwendeten Programme nicht an,
sie werden hinter Fortschrittsbalken versteckt. Weil ich gerne den vollen Überblick
behalte, benutze ich Grip
nur wenn die FreeDB schweigt.
mencoder
Der iRiver H340 spielt seit Firmware 1.28 auch Videos ab, falls sie als AVI vorliegen und kompatibel sind. Was genau kompatibel ist weiß ich nicht, 220x176 Pixeln, 10 fps, MP4-Video, MP3-Ton, nicht zu hohe Bitrate scheint aber zu passen.
Zur Umwandlung von vorhandenen Videos in das passende Format bietet sich der mencoder
an, er gehört zum Port /usr/ports/multimedia/mplayer. Die Optionen die mencoder
versteht, stimmen größtenteils mit denen von mplayer
überein, das gleiche gilt für die
erlaubten Eingabeformate. Kann ein Film mit mplayer
abgespielt werden, kann man ihn auch mit
mencoder
transkodieren.
Für den iRiver passende Videos erzeugt man mit der Kommandozeile:
mencoder $quelle -alang en -srate 44100 -af-adv force=1 -oac mp3lame -lameopts mode=2:cbr:br=128 -vf expand=:$hoehe,scale=220:176,filmdint=io=25:10,pp=fd -sws 9 -ofps 10 -ovc lavc -lavcopts vbitrate=312 -ffourcc XVID -o $ziel
Die mplayer-Manpage gibt einen Überblick, welche Werte für $quelle
erlaubt sind.
Getestet habe ich mit DVDs, bei anderen Quellen fallen ein paar der von mir benutzten Optionen weg.
-alang en
sorgt dafür, dass mencoder
den englischen Originalton
transkodiert.
-oac mp3lame -lameopts mode=2:cbr:br=128
gibt das Tonformat an:
MP3 mit konstanter Bitrate. -srate 44100
lässt mencoder
den Ton vor der Kodierung auf 44,1 kHz resamplen, -af-adv force=1
verhindert, dass dabei hörbare Artefakte auftreten. Der iRiver spielt auch Videos mit einer
48-kHz-Tonspur ab, allerdings in der falschen Tonlage.
-vf
kündigt verschiedene Video-Filter an. scale=220:176
ist selbsterklärend,
filmdint=io=25:10
reduziert die Framerate, damit sich der iRiver nicht verschluckt.
pp=fd -sws 9
verbindet die Halbbilder, ob es nötig ist hängt von der Quelle ab.
Bei europäischen Filmen ist es meist unnötig, meine Quelle kam aus Amerika.
-ovc lavc -lavcopts vbitrate=312 -ffourcc XVID
konfiguriert den Video-Encoder.
Das Bild wird mit 312 Bits pro Sekunde kodiert und das Ergebnis als xvid deklariert.
Die Anzeige des H340 entspricht keinem Standard-Video-Seitenverhältnis, bei der Transformation gibt es drei Kompromisse:
Ich habe mich für die dritte Möglichkeit entschieden. Dafür muss mencoder
das Bild vor der Verkleinerung vertikal vergrößern (nicht strecken) – geregelt wird
es mit expand=:$hoehe
.
Die Werte für $hoehe
hängen vom Seitenverhältnis und der Auflösung des
Eingangsvideos ab, sie müssen von Hand errechnet werden.
Für Vollbild-DVDs beträgt der Wert
614, für anamorph kodierte DVDs
858 und so weiter.
rsync
Um die Dateien vom Rechner auf den H340 zu bringen, nutze ich rsync
aus dem Port /usr/ports/net/rsync.
Auf dem Rechner habe ich ein Verzeichnis ~/iriver-spiegel
,
der iRiver H340 wird mit mount_msdosfs /dev/da0s1 /mnt/iriver/
gemountet und mit rsync -rva ~/iriver-spiegel/ /mnt/iriver/
befüllt.
Dabei werden nur die Dateien übertragen, die auf dem iRiver fehlen, aber auf dem Rechner vorhanden sind. In die andere Richtung wird nicht abgeglichen.
Sollte mehrere USB-Geräte angeschlossen
sein, ist der H340 eventuell nicht unter /dev/da0
ansprechbar. dmesg
verrät mehr. Nach Anstecken erhalte ich auf dem Laptop:
umass0: iRiver iRiver H300 Series, rev 2.00/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: <TOSHIBA MK4004GAH JD00> Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 38147MB (78126048 512 byte sectors: 255H 63S/T 4863C)
Auf dem nur USB-1-sprechenden Server:
umass0: iRiver iRiver H300 Series, rev 2.00/1.00, addr 2 da0 at umass-sim0 bus 0 target 0 lun 0 da0: <TOSHIBA MK4004GAH JD00> Fixed Direct Access SCSI-0 device da0: 1.000MB/s transfers da0: 38147MB (78126048 512 byte sectors: 255H 63S/T 4863C)