|
Seiten: 1 [2]
|
 |
|
Autor
|
Thema: Audiograbber 1.80 -> Qualität beim Encoden (Gelesen 4090 mal)
|
Jens Mueller
Erfahrenes Mitglied
 Offline
Beiträge: 133
Suum cuique
|
Meine Theorie: AG liefert die Daten, Codec macht daraus Stille, AG schneidet die Stille ab.
Aber da sollte sich wirklich mal Jackie drum kümmern, kannst ihm ja Deine WAV-Datei schicken ...
|
|
|
|
« Letzte Änderung: 1. Januar 1970, 01:00:00 von 1022968800 »
|
Gespeichert
|
|
|
|
fperau
Einsteiger
Offline
Beiträge: 10
|
Hi Jens!
Wäre vielleicht eine mögliche Theorie!?
Mich würde mal interessieren, ob es irgendwo Infos darüber gibt, welche Eigenschaften der Fraunhofer-Codec oder andere Codecs überhaupt haben - meine jetzt Eckfrequenzen, Bandbreite etc.!
Hast du einen Hinweis für mich, wo ich so etwas finden könnte?
Auf der Fraunhofer-Page bzw. auf dem Spill-Out von denen finde ich alles mögliche, nur leider keine konkreten Hinweise auf Daten oder Fakten.
Bevor ich Jackie kontaktiere, warte ich mal ab, ob Stefan sich mal meldet - vielleicht weiß er noch etwas mehr darüber?!
Jackie wird sicher genug zu tun haben - denke ich jedenfalls.
Also, lieber Stefan, hast du noch eine Ahnung oder Hinweise auf Infoquellen?
S T E F A N . . . ! ;-)
Oder sucht er noch die Ostereier??? :-)
Grüße an alle,
Frank
P.S. Eigentlich finde ich es auch etwas merkwürdig, daß hier bis jetzt "nur" ein Zwiegespräch entstanden ist. Denn Rippen und Archivieren findet sicher nicht nur bei mir statt! Oder legen alle anderen wirklich nur Wert auf Geschwindigkeit?
Dann wäre es ja auch kein Wunder, daß die Encoder einfach nur schnell und qualitativ weniger gut gemacht werden, also das der Kompromiß zwischen Qualität und Geschwindigkeit so niedrig aufgehängt ist...
Ich kann doch keine so große Ausnahme sein - oder?
|
|
|
|
« Letzte Änderung: 1. Januar 1970, 01:00:00 von 1022968800 »
|
Gespeichert
|
Geht nicht, gibt's nicht...!
|
|
|
Jens Mueller
Erfahrenes Mitglied
Offline
Beiträge: 133
Suum cuique
|
fperau: Die anderen haben halt möglicherweise nicht soviel Ahnung von Frequenzen, psychoakustischen Modellen, Fourier-Analyse etc.
Stefan ist übrigens zur Zeit im Urlaub. Und scheu Dich nicht, Jackie zu kontaktieren, der kennt sich mit den "Innereien" von AG am besten (bzw. als einziger?!) aus.
|
|
|
|
« Letzte Änderung: 1. Januar 1970, 01:00:00 von 1022968800 »
|
Gespeichert
|
|
|
|
fperau
Einsteiger
Offline
Beiträge: 10
|
Hi Jens!
Danke auch für deinen bisher investierten "Hirnschmalz"!
Ich habe eben versucht, die Kontaktadresse von Jackie herauszufinden - leider erfolglos.
Vielleicht hab' ich ja Ostereier auf den Klüsen...?
Zu deiner Aussage oder Vermutung, daß "andere" nicht so viel Ahnung haben könnten, will ich bemerken, daß die "anderen" aber eigentlich auch Ohren haben müßten - zumindest die Brillenträger! :-)
Oder kann es möglich sein, daß die "anderen" tatsächlich nicht so viel Wert auf die Qualität, sondern eher auf Quantität legen - weil so ja auch eine erheblich größere Menge an MP3-Files auf die HD's passen???
Das kann ich ja auch sehr gut verstehen, daß man dann seine "Meßlatte" für den Kompromiß zwischen Dateigröße und Qualität sehr niedrig aufhängt.
Aber trotzdem wundere ich mich ein wenig darüber, daß du scheinbar der einzige bist, den diese "Sache" überhaupt interessiert...
Machen wir uns nichts vor, Jens - die technischen Möglichkeiten werden wie immer weiter steigen und die HD-Kapazitäten werden weiter zunehmen und irgendwann werden sich eine ganze Menge Leute darüber ärgern (oder auch nicht), daß ihre alte Vinylsammlung doch eigentlich in wesentlich besserer Qualität hätte archiviert werden können...
"Kann ich nochmal von vorne???"
Ich habe Musikstücke, in denen eine Background-Sopranistin bis zu 22 kHz "hochkommt" - im Original kannst du sie sehr gut hören, nur im encodeten MP3-File ist sie leider fast verschwunden...
Auch durch die Heraufsetzung der Datenrate von 192 auf 320 kBit/s kann dieses Manko leider nicht beseitigt werden. Und das stört mich eben auch ein wenig. Das ein Codec seine Grenzen hat und auch haben muß, ist völlig logisch - aber mich interessiert eben auch das warum und wieso, weil meiner bescheidenen Meinung nach ein Bug zur Zeit definitiv nicht ausgeschlossen werden kann. Die Tatsache, daß es bei anderen Codecs und/ oder Encodern nicht wesentlich besser ist, heißt ja nicht automatisch, daß nicht alle den gleichen Bug implementiert haben könnten! Oder?
Außerdem habe ich das Ergebnis von CoolEdit Pro 1.2a und das sieht mit Abstand am besten aus.
Mein Wunsch wäre, daß der Audiograbber als Spezialsoftware ein ebenso gutes Encoder-Ergebnis liefern kann, denn schließlich ist CoolEdit Pro kein Encoder mit den sonstigen Eigenschaften eines Encoders.
Ob das wohl möglich sein könnte?
Grüße an alle Interessierten,
Frank Perau
P.S. Jens - hast du einen Plan, wie ich Jackie erreichen kann?
|
|
|
|
« Letzte Änderung: 1. Januar 1970, 01:00:00 von 1022968800 »
|
Gespeichert
|
Geht nicht, gibt's nicht...!
|
|
|
Jens Mueller
Erfahrenes Mitglied
Offline
Beiträge: 133
Suum cuique
|
Schau doch mal auf Audiograbber.org oder so nach ...
|
|
|
|
« Letzte Änderung: 1. Januar 1970, 01:00:00 von 1022968800 »
|
Gespeichert
|
|
|
|
jaybee
Erfahrenes Mitglied
Offline
Beiträge: 207
|
Hallo Frank!
Ich hab da mal eine allgemeine Bemerkung zu deinem "Encodertest". Also, generell beruht MPEG-Audiokompression darauf, daß das Signal in Frequenzbänder unterteilt wird. In den für das Gehör unwichtigeren Bändern wird dann Quantisierungsrauschen eingefügt. Dieses Verfahren funktioniert perfekt bei einem Eingangssignal, das zum Beispiel aus einer Sinuswelle besteht. Daher sind Encodertests, die eine Sinuswelle benutzen, nicht sinnvoll: Jeder noch so schlechte Encoder erkennt sofort, daß nur in einem Band Daten anliegen und benutzt seine komplette Bandbreite dafür. Wenn man dagegen auf allen Bändern ein Signal anlegt, erkennt man die Fähigkeiten eines Encoders sehr gut - allerdings darf das Signal kein (wichtig!) Rauschen sein. Der Encoder würde dann nämlich bei Bändern, die nur mit wenigen Bits abgelegt sind, Quantisierungsrauschen einfügen, das von dem eigentlichen Rauschen praktisch nicht zu unterscheiden ist.
Am besten zum Testen eignen sich nach meinen Erfahrungen: Klassische Musik und Liveaufnahmen (das Klatschen ist ein Rauschen mit genügend Struktur, um den im Vergleich zum Applausrauschen eher niederfrequenten Pre-Echo Fehler zu hören der auftritt, wenn ein Signal sich schnell (innerhalb 1 Sekunde) ändert z.B. von 50 Hz auf 10 kHz.) und für Tests mit niedrigeren Bitraten eignet sich Sprache ganz wunderbar.
Gruß
jaybee
|
|
|
|
« Letzte Änderung: 1. Januar 1970, 01:00:00 von 1022968800 »
|
Gespeichert
|
|
|
|
Stefan
Administrator
Experte
Offline
Beiträge: 665
AG-Support
|
Ich werde es mir morgen mal in Ruhe durchlesen. Heute bin ich einfach zu müde, bin jetzt seit 48h durchgehend auf den Beinen... 
|
|
|
|
« Letzte Änderung: 1. Januar 1970, 01:00:00 von 1022968800 »
|
Gespeichert
|
|
|
|
Stefan
Administrator
Experte
Offline
Beiträge: 665
AG-Support
|
Soo, das war ganz schön viel Text, den ich hier lesen musste 
Und ziemlich viele Fragen auf einmal... fangen wir mit den leichten an: die Email-Adresse von Jackie ist jackie@audiograbber.com-us.net. In solchen Fragen ist er ein sehr kompetenter Ansprechpartner.
Zu dem Problem mit dem Xing-Encoder (AudioCatalyst): das Abschneiden der hohen Frequenzen (>15 KHz) war eigentlich immer DAS Problem dieses Encoders. Da haben sich schon viele Leute drüber aufgeregt. Aber da bei Xing nichts mehr entwickelt wird, seit sie von Real aufgekauft wurden, wird sich das wohl auch nicht mehr ändern.
fperau: Hast du denn Lame schon mal probiert? Im jetzigen Entwicklungsstand kann es sich absolut mit Fraunhofer messen, mich würde mal interessieren, wie der sich in den verschiedenen Einstellungen verhält.
Wer jetzt die ms am Anfang und am Ende wegschneidet, AG oder der Codec, weiss ich auch nicht. Vielleicht weiss Jackie da ja eine Antwort.
Aber seltsam ist es wirklich (auch wenn es wohl kaum einer mitkriegt). Gut, dass es noch so aufmerksame User gibt 
|
|
|
|
« Letzte Änderung: 1. Januar 1970, 01:00:00 von 1022968800 »
|
Gespeichert
|
|
|
|
Jens Mueller
Erfahrenes Mitglied
Offline
Beiträge: 133
Suum cuique
|
Jaybee, kannst Du dieses "Quantisierungsrauschen" nochmal näher erläutern? Vielleicht auch besser in einem neuen Thread im MP3-Forum ...
|
|
|
|
« Letzte Änderung: 1. Januar 1970, 01:00:00 von 1022968800 »
|
Gespeichert
|
|
|
|
jaybee
Erfahrenes Mitglied
Offline
Beiträge: 207
|
Das prinzipielle Verfahren des Quantisierers ist folgendes: Wenn die Signalintensität eines Subbandes unter dessen Maskierung liegt, muß das Signal gar nicht kodiert werden, weil es unhörbar bleibt. Ansonsten werden die Frequenzsamples mit gerade so vielen Bits quantisiert, daß das dadurch eingeführte Quantisierungsrauschen durch die Maskierung gerade noch unhörbar bleibt.
Für jede Gruppe von 3x12 Samples eines Subbandes gibt es einen Wert, der angibt, mit wie vielen Bits Auflösung diese Samples quantisiert werden und bis zu drei Skalierungsfaktoren (höchstens einer für 12 Samples). Die Skalierungsfaktoren werden bei der Dekodierung mit den quantisierten Samples multipliziert, wodurch sich eine Verbesserung der Quantisierungsauflösung ergeben kann. Drei Skalierungsfaktoren pro Block werden nur verwendet, wenn es unbedingt nötig ist, um Verzerrungen des Signals zu vermeiden. Skalierungsfaktoren werden von zwei oder allen drei 12er-Gruppen gemeinsam genutzt wenn: (1) sich die Werte der Skalierungsfaktoren ähnlich genug sind, oder (2) wenn der Kodierer erkennt, daß die zeitliche Maskierung des Gehörs die eingeführten Fehler unhörbar macht.
Es wird eine Iterationsschleife durchlaufen, die Quantisierungsparameter in geordneter Weise variiert, die Samples quantisiert und das dadurch erzeugte Quantisierungsrauschen tatsächlich ausrechnet, um zu prüfen, ob es im unhörbaren Bereich bleibt. Wenn dies nicht der Fall ist, wird für die entsprechenden Subbänder eine feinere Quantisierung gewählt ("noise allocation"). Diese Schleife benötigt den Hauptteil der Rechenzeit beim Quantisierungsprozeß. Außerdem werden die quantisierten Samples zusätzlich Huffman-kodiert, um eine weitere Reduzierung des Speicherbedarfs zu erzielen. Die verwendeten Huffman-Bäume sind statisch.
Für ein Audiosignal, das mit einer Abtastfrequenz von 44,1 kHz aufgezeichnet wurde und durch Kompression auf eine Datenrate von 128 kBit/s reduziert werden soll, ergibt sich pro Datenblock eine Größe von:
1152 (Samples/Block) x 128000 (Bits/s) / 44100 (Samples/s) = 3344 (Bits/Block)
Benötigt ein Block weniger als die diese Anzahl an Bits, so werden die übrigen Bits an das sogenannte "Bit-Reservoir" übergeben. Läßt sich umgekehrt ein Block nicht ohne hörbaren Qualitätsverlust mit der vorgegebenen Blockgröße kodieren, so können Bits aus dem Bit-Reservoir entnommen werden, die zusätzlich zur Kodierung des Blocks verwendet werden. Die Blöcke, die nicht die ganze Blockgröße benötigen, werden mit Daten der nächsten Blöcke aufgefüllt; siehe Bild 8. Es dürfen jedoch zu keiner Zeit mehr Bits entnommen werden als im Bit-Reservoir vorhanden sind.[1]
Ich denke, das lässt keine Fragen offen.
jaybee
[1] http://goethe.ira.uka.de/seminare/redundanz/vortrag14/#quantisierung
|
|
|
|
« Letzte Änderung: 1. Januar 1970, 01:00:00 von 1022968800 »
|
Gespeichert
|
|
|
|
|
Seiten: 1 [2]
|
|
|
|
|
|
|
