Videosammlung nach h265 konvertieren
- Ersteller soturi
- Erstellt am
turrican
Well-Known Member
kann mich noch vage erinnern - irgendwann rippte man damals seine CDs anstatt nach .mp3 auf einmal nach .ogg weil ogg schliesslich open, hip und angeblich (ich konnte mit meinem Gehör nie nen Unterschied hören) eh besser als mp3 - und hatte dann auf der Platte ne Mischung aus mp3 und ogg, wobei man die ogg nirgends sonst ausser am PC anhören konnte, so gut wie keine externen Player konnten das Format damals...
Man muss allerdings auch klar sagen: Es gibt für Musikkonsumenten nur wenige rationale Argumente für verlustfreie Kompression. Man macht es halt, weil Speicherplatz billig ist und die Dateien in Relation zu heutigen Festplatten recht klein sein. Aber darüber hinaus sind verlustbehaftete Audio-Codecs mit guten psychoakustischem Modell und ausreichend Bitrate nachweislich transparent, also im Blindhörtest von einer verlustfrei komprimierten Quelle nicht zu unterscheiden.
Der schlecht Ruf verlustbehaftet komprimierter Musik kommt vor allem aus der Anfangszeit von mp3. Die ersten mp3-Encoder, wie Frauenhofers Referenzimplementierung, hatten bescheidene psychoakustische Modelle und erzeugten selbst bei 320 kbit/s Stereo hörbare Artefakte. Gleichzeitig war zu der Zeit mangels Speicherplatz und Bandbreite viele Musik mit 128 kbit/s Stereo totkomprimiert. mp3 machte einen Qualitätssprung um ganze Universen, als Anfang des Jahrtausends lame mit seinem gegenüber anderen Encodern massiv verbesserten psychoaktustischen Modell kam.
Und dann war auch schnell die zweite Codec-Generation da. Vorbis im freien Bereich und AAC im kommerziellen. Beide waren effizienter als mp3, kamen also mit weniger Bandbreite aus und hatten gleich von Anfang an ein gutes psychoakustisches Modell. Apple entschied sich nicht ohne Grund gegen mp3 und für AAC, denn damit konnten sie über iTunes gute Qualität bei vergleichsweise kleinen Dateien liefern. AAC litt auf dem freien Markt nur lange darunter, dass die freien Encoder (vor allem libfaac) eher bescheiden waren und die Bandbreite schlecht ausnutzten. Was dann wieder zu schlechter Qualität führte.
Inzwischen ist Opus sowieso über alles erhaben. 48 kbit/s (also 96 kbit/s Stereo) pro Kanal sind genug, um zu CDs transparent zu sein. Wer sich was gönnen will, nimmt 64 kbit/s pro Kanal (also 128 kbit/s Stereo) und ist glücklich. Der Fortschritt findet im Moment eher bei extrem niedrigen Bitraten bis 32 kbit/s und immer niedrigeren Latenzenstatt. Da aber nicht so sehr für Musik, stattdessen für DInge wie Videokonferenzen.
Das war tatsächlich das einzig gute an iTunes, man konnte unkompliziert eine CD in gutes AAC rippen 
Daher sind großteils meiner alten Musikfiles auch AAC und hören sich top an.
Richtig mieß war natürlich, dass iTunes auch sämtliche MP3s, die man über umwege bekommen hat, wenn man sie auf den iPod schob, in AAC konvertiert hat, das klang dann richtig Müll, das konnte man damals schon hören.
Daher sind großteils meiner alten Musikfiles auch AAC und hören sich top an. Richtig mieß war natürlich, dass iTunes auch sämtliche MP3s, die man über umwege bekommen hat, wenn man sie auf den iPod schob, in AAC konvertiert hat, das klang dann richtig Müll, das konnte man damals schon hören.
Andrew7510
New Member
Ja, genau! iTunes war echt gut für das Rippen von CDs in AAC. Die Qualität war top, hab das auch oft genutzt.
Aber das mit dem Konvertieren von MP3s zu AAC war echt nervig. Die Qualität litt total drunter. Hatte damals viele Tracks, die sich danach echt mies angehört haben.
Gruß, Andrew
Aber das mit dem Konvertieren von MP3s zu AAC war echt nervig. Die Qualität litt total drunter. Hatte damals viele Tracks, die sich danach echt mies angehört haben.
Gruß, Andrew
Insgesamt bei heutigen Festplattenpreise aber echt eine merkwürdige Diskussion. Hier gibt es 8TiB für 120€ :
Ich denke, die Zeit, die du mit Researching von Codec-Parametern verbracht hast, ist schon teurer
Seagate BarraCuda Compute 8TB ab € 125,64 (2024) | Preisvergleich Geizhals Deutschland
✔ Preisvergleich für Seagate BarraCuda Compute 8TB ✔ Bewertungen ✔ Produktinfo ⇒ Kapazität: 8TB (entspricht ca. 7450.58GiB bzw. 7.28TiB, weiterführende Informationen hierzu ) • Formfakto… ✔ Hard Disk Drives (HDD) ✔ Testberichte ✔ Günstig kaufengeizhals.de
HGST 8TB 3,5" SAS 12G 7,2K HDD Festplatte HUH728080AL5200 Server Storage | eBay
HGST 8TB 3,5" SAS 12G 7,2K HDD Festplatte HUH728080AL5200 0F23746. >>> Modell: HUH728080AL5200 <<<. 1 x 8TB SAS HDD HUH728080AL5200 P/N: 0F23746. >>> HGST P/N: 0F23746 <<<. Technical data / Technische Daten.
www.ebay.de
Das Sonderangebot endet in ~10h und dann ist es immer noch der beste Schnapp derzeit auf ebay. Bei Mindestabnahme von vier Stück 4,49€/TB. Es sind SAS3/12G-Platten, funktionieren daher nicht am SATA-Controller.
Umschiffbares Minimanko: die haben SUN-Firmware (nicht wirklich, es ist ein config-overlay höchstwahrscheinlich von einem SUN Oracle DE3-24 JBOD, Details würden aber den Rahmen sprengen) und melden sich als
HGST H7280A520SUN8.0T vs. die reguläre mit der generic Firmware HGST HUH728080AL5200lauten würde. Das soll uns aber nicht interessieren, denn sie sind nicht gesperrt für "white boxes". Auf dem Label steht was von eingeschränktem block count bei 512b, außerdem Formatted with type 1 protection und das kostet 8 bytes je block. Die Sunkist mag das so haben wollen, wir brauchen das mit ZFS alles nicht und wollen sowieso AF/4kn nutzen.
Wir gucken zunächst mal
smartctl -x /dev/daX:
Code:
...
=== START OF INFORMATION SECTION ===
Vendor: HGST
Product: H7280A520SUN8.0T
Revision: PD51
Compliance: SPC-4
User Capacity: 7,865,536,647,168 bytes [7.86 TB]
Logical block size: 512 bytes
Physical block size: 4096 bytes
Formatted with type 1 protection
8 bytes of protection information per logical block
LU is fully provisioned
Rotation Rate: 7200 rpm
...oder
sg_readcap /dev/daX:
Code:
READ CAPACITY (10) indicates device capacity too large
now trying 16 byte cdb variant
Read Capacity results:
Protection: prot_en=1, p_type=0, p_i_exponent=0 [type 1 protection]
Logical block provisioning: lbpme=0, lbprz=0
Last LBA=15362376263 (0x393ab4247), Number of logical blocks=15362376264
Logical block length=512 bytes
Logical blocks per physical block exponent=3 [so physical block length=4096 bytes]
Lowest aligned LBA=0
Hence:
Device size: 7865536647168 bytes, 7501160.3 MiB, 7865.54 GB, 7.87 TBOk, dann formatieren wir mal. Alles explizit:
sg_format --format --pfu=0 --fmtpinfo=0 --size=4096 -vv /dev/daX oder mit camcontrol:
Code:
camcontrol cmd daX -v -c "15 10 0 0 v:i1 0" 12 -o 12 "0 0 0 8 0 0:i3 0 v:i3" 4096
camcontrol format daX -v12h Stunden später:
Code:
...
=== START OF INFORMATION SECTION ===
Vendor: HGST
Product: H7280A520SUN8.0T
Revision: PD51
Compliance: SPC-4
User Capacity: 8,001,563,222,016 bytes [8.00 TB]
Logical block size: 4096 bytes
LU is fully provisioned
Rotation Rate: 7200 rpm
...Weil die modepages auch umgeschrieben wurden und SAS ja dualport ist, sollten wir sie zur Sicherheit einmal zupfen und wieder reinhängen, damit sich alles auch berappeln kann:
camcontrol stop daX... ~15 secs
abziehen
wieder dranstecken
Da eh jeder Bereich gebügelt wurde, hat man damit auch einen Burn-in gefahren.
Wenn jetzt noch
Elements in grown defect list: 0 und Total uncorrected errors (r/w/v) 0 anzeigen, ist alles perfekt und man kann sie in den zfspool hängen.Meine hatten um die ~57000h Laufzeit runter, aber das ist egal. a) sind es HGSTs, die sind robust bis übermorgen und noch weiter und b) wenn doch eine platzt oder heliummäßig davonschwebt...wat solls, nächste nachstecken.
Bonusinfo:
die modepages lassen sich permanent setzen,
sdparm -s WCE=1 -S /dev/daX als prominentestes Beispiel.Manual: https://usermanual.wiki/m/fbb0f07e9cdbae493b2a278fff4e0cb543fc784d8283040cfc7ba311995e0595
Die Steps der Firmware bei Sun waren, wenn meine Recherche korrekt ist, sorum: P554->P9E2->PD51
PD51 wäre dann glücklicherweise eh die letzte, ist ja alles hinter der paywall.