Test zu neuartigen Matrix-encodierter Lame-MP3's

Also der Teil mit der Verbesserung des MP3-Encodierens durch Matrix-Einwirkung ist hiermit erstmal abgeschlossen, denn ich konnte laut Bit-Compare keine Unterschiede feststellen. Zumindest gilt dies für meinen Versuch "von außen". Vielleicht gibt es eine Möglichkeit dies im Codec zu verwenden, aber das übersteigt meine Möglichkeiten, da ich nicht programmieren kann.
Hier die verwendeten Zeilen und noch andere

------echt-stereo------
-b320 -q2 --lowpass 20000 -X0 --scale 0 -ms
-b256 -q2 --lowpass 19500 -X0 --scale 0 -ms

------joint-stereo-----
-b224 -q2 --lowpass 20000 -X0 --scale 0 -mj
-b192 -q2 --lowpass 19500 -X0 --scale 0 -mj
--preset cbr 160 -q2 --lowpass 18500 -X0 --scale 0 -mj
--preset cbr 128 -q2 --lowpass 14800 --scale 0 -mj
--preset cbr 112 -q2 --lowpass 14800 --scale 0 -mj
--preset cbr 112 -q2 --lowpass 12000 --scale 0 -mj
--preset cbr 96 -q2 --lowpass 12000 --scale 0 -mj --resample 44
--preset cbr 96 -q2 --lowpass 12000 --scale 0 -mj
--preset cbr 80 -q2 --lowpass 12000 --scale 0 -mj
--preset cbr 64 -q2 --lowpass 12000 --scale 0 -mj --resample 24
--preset cbr 64 -q2 --lowpass 12000 --scale 0 -mj
--preset cbr 56 -q2 --lowpass 10200 --scale 0 -mj
--preset cbr 48 -q2 --lowpass 8200 --scale 0 -mj --resample 22
--preset cbr 48 -q2 --lowpass 9400 --scale 0 -mj

------mono------
-b112 -q2 --lowpass 19500 -X0 --scale 0 -mm
-b96 -q2 --lowpass 19000 -X0 --scale 0 -mm
--preset cbr 80 -q2 --lowpass 18500 -X0 --scale 0 -mm
--preset cbr 64 -q2 --lowpass 14800 --scale 0 -mm
--preset cbr 56 -q2 --lowpass 12000 --scale 0 -mm
--preset cbr 48 -q2 --lowpass 10500 --scale 0 -mm --resample 44
--preset cbr 48 -q2 --lowpass 12000 --scale 0 -mm
--preset cbr 40 -q2 --lowpass 10500 --scale 0 -mm
--preset cbr 40 -q2 --lowpass 10500 --scale 0 -mm --resample 24
--preset cbr 32 -q2 --lowpass 8300 --scale 0 -mm
--preset cbr 24 -q2 --lowpass 7200 --scale 0 -mm
--preset cbr 16 -q2 --lowpass 6100 --scale 0 -mm
--preset cbr 16 -q2 --lowpass 3800 --scale 0 -mm --resample 16
--preset cbr 8 -q2 --lowpass 3070 --scale 0 -mm --resample 11
--preset cbr 8 -q2 --lowpass 2600 --scale 0 -mm

Um noch mal auf meine Frage mit dem wav zurück zu kommen:

pelmazo schrieb:

Wenn die Absenkung mit korrektem Dithering erfolgt, dann ist das Resultat nicht identisch. Oder andersrum: Wenn die Resultate identisch sind wurde nicht gedithert.

Also sollte theoretisch es möglich sein, identische Files zu erzeugen? Ich habe es bisher nicht geschafft Basis-Wav(-5dB) mit dem 2.wav(-5dB) identisch zu bekommen.

Es ist nicht unmöglich, identische Files zu bekommen. Der springende Punkt ist aber daß es wenn überhaupt dann nur ohne Dithering geht, und damit falsch wäre. Selbst wenn man das in Kauf nimmt kann es immer noch zu Unterschieden durch Rundungsfehler kommen.

Im EAC geht es mit Normalisieren, sagen wir z.B. auf 90% (als Basis) dann 1-2% hoch und zurück auf 90% auch nicht identisch hinzubekommen.
Also würde ich jetzt davon ausgehen, dass jeder Prozess, welcher in irgend einer Form eine Neucodierung erfordert, Veränderung bzw. Verlust im Klang durch Rundungsfehler zur Folge hat.
Das würde sich mit meinen Erfahrungen decken, welche ich bisher mit diverse Soundbearbeitungs-Programmen gemacht habe.
Mit anderen Worten, je mehr Tools (EQ, Normalizer, Leveler, Noise Gate, usw.) zum "Verbessern" oder "Optimieren" des Klanges gebraucht werden, desto weniger kommt hinten vom einstigen originalen Signal (mal abgesehen von der beabsichtigten Veränderung) an.
Habe ich das richtig zusammen gefasst?

Mit anderen Worten, je mehr Tools (EQ, Normalizer, Leveler, Noise Gate, usw.) zum "Verbessern" oder "Optimieren" des Klanges gebraucht werden, desto weniger kommt hinten vom einstigen originalen Signal (mal abgesehen von der beabsichtigten Veränderung) an. Habe ich das richtig zusammen gefasst?

Du veränderst ja das Signal, folglich ist das Ergebnis natürlich nicht mehr deckungsgleich zur Quelle. So einfach aufsummieren kann man das aber mit Sicherheit nicht.

zur lautstärkeveränderung:

selbst, wenn man die lautstärke um 0,1 dB absenkt, speichert, danach wieder um 0,1 dB erhöht, ändert sich das signal. eine bit-comparison wird unterschiede zwischen original und lautstärkeveränderter datei finden.

und dabei ist es egal, ob die berechnung in 16/44,1 oder 24/96 gemacht worden ist oder ob dithering erfolgte oder nicht. es gibt keinen audio-editor, der beim verändern einer datei "nichts verändert".

alles, was man mit einer musikdatei macht, verändert sie. die daten werden in jedem fall prozessiert.

was anderes ist replay-gain. da wird nur die lautstärke des abspielenden players über infodaten in der musikdatei beeinflusst, nicht aber die datei selbst.

soviel dazu...

Cavaille schrieb:

alles, was man mit einer musikdatei macht, verändert sie. die daten werden in jedem fall prozessiert.

Gilt das auch, wenn ich eine Musik-Datein von einem Lossless-Format in ein anderes wandle, also z.B. von WAV nach FLAC, von FLAC nach ALAC usw.?

Die Wandlung eines Lossless-Formates in ein anderes Lossless-Format soll ja absolut verlustfrei sein - was somit heissen würde, dass nicht ein Bit verloren gehen darf/verändert wird (z.B. bei Rückwandlung nach WAV müsste ein absolut identisches Ergebnis wie die ursprüngliche WAV-Datei vorliegen).

Greez
Paesc

Ich habe extra ein niedrigeres Niveau als Basis benutzt, um es dann ein wenig zu erhöhen und wieder abzusenken. Weil, wenn man 100% zu 90% und wieder zu 100% zurückwandelt, gehen schon der Logik nach Daten verloren.
Bei Flac jedoch habe ich schon mal Testweise 5x hin und her gewandelt, da sind keine Unterschiede mit Bit-Compare zu ermitteln (es soll ja auch keine Lautstärke oder der Klangänderung stattfinden).
Wenn man allerdings z.B. 10x Wav 90% zu 92% und zurück zu 90% wandelt, gehen 10x Daten verloren. Stelle man sich also mal eine aufwendige Soundbearbeitung vor (weil in den einzelnen Modulen ja schon x-fach neu berechnet wird), was dann noch übrig bleibt.
Einzige Ausnahme ohne Verlust wäre wohl das Abspeichern aus dem Editor, wenn man nur schneidet oder zusammenfügt.

deltaalpha66 schrieb:

Habe ich das richtig zusammen gefasst?

Jein. Es stimmt zwar daß praktisch jede Veränderung am Signal auch Fehler (z.B. Rundungs- oder Quantisierungsfehler) hinzufügt. Es wäre aber verkehrt, das generell als Verschlechterung darzustellen. Aus mehreren Gründen:

Das erwähnte Dithering sorgt dafür, daß aus solchen Fehlern keine nutzsignalkorrelierten Störsignale entstehen, sondern allenfalls ein minimal stärkeres Grundrauschen. Das tut man eben gerade damit sich die Klangfärbung nicht ändert.

Die meisten Veränderungen am Signal sollen ja gerade den Klang ändern, dafür macht man's ja. Selbst eine Lautstärkeänderung ist nicht völlig klangneutral (auch bei Analogsignalen nicht!), denn zum Einen verändert sich mit dem Pegel der Frequenzgang des Ohres (Loudnesskurve), zum Anderen verändert sich der nutzbare Dynamikbereich (Rauschabstand und Headroom).

Die bei der Digitaltechnik entstehenden Fehler kann man im Prinzip beliebig klein machen indem man die Wortlängen passend wählt. So wird im Studio heute fast durchgängig mit 24 bit oder mehr gearbeitet, wodurch sich bei sonst gleichen Bedingungen gegenüber den 16 bit der CD die Fehler um den Faktor 256 verringern. Bei der Analogtechnik ist das ungleich schwieriger oder gar unmöglich. Anders gesagt: Die Fehler der Digitaltechnik entspringen mathematischen Gesetzmäßigkeiten, die Fehler der Analogtechnik physikalischen Gesetzmäßigkeiten. Erstere kann man weitaus leichter minimieren als Letztere.

Bitweiser Vergleich zweier Digitalsignale liefert keinen brauchbaren Maßstab für einen Klangvergleich. Wenn die Bitgleichheit gegeben ist müssen die Signale gleich klingen, wenn sie nicht bitgleich sind kann man aber über die Hörbarkeit der Unterschiede rein gar nichts aussagen. Zwei Signale können sich in allen Abtastwerten unterscheiden und doch völlig gleich klingen. Bitweiser Vergleich hat nur einen Sinn: Herauszufinden ob ein Signal eine exakte Kopie eines anderen Signals ist. Das braucht man zur Beurteilung der Zuverlässigkeit von Kopierverfahren und/oder von verlustfreien Kodierungsverfahren. Das ist eine vom Klang völlig unabhängige Fragestellung.

Selbst wenn man eine CD (oder .wav-Datei, oder...) ohne jede weitere Signalverarbeitung direkt abspielt, dann passiert das Signal immer noch einen D/A-Wandler, und in dem wird wie wild mit dem Signal herumgerechnet. Das ist die selbe Art von Mathematik wie bei den sonstigen Digitalfiltern, mit den gleichen Problemen bzgl. Rundungsfehlern u.s.w., folglich gibt es so etwas wie eine "fehlerfreie Wiedergabe" nicht. Die in heutigen D/A-Wandlern enstehenden Fehler sind aber in der Regel vernachlässigbar gegenüber den Fehlern der nachgeschalteten Gerätschaften, insbesondere der Lautsprecher.

Es hat also keinen Sinn, die Fehler der Digitaltechnik zu beklagen, denn alles Andere hat auch Fehler. Musiker, Instrumente, Mikrofone, Mischpulte, Effektgeräte, Aufzeichnungsgeräte, Abspielgeräte, Verstärker, Lautsprecher, die Raumakustik, das menschliche Ohr und das menschliche Gehirn haben alle ihre spezifischen Probleme, die sich auf das Ergebnis auswirken können. Das Einzige was hier Sinn hat ist, die Fehler der Bedeutung und Größenordnung nach zu werten, und diese Wertung ist bei Deiner Betrachtung völlig unter den Tisch gefallen.

Wie sieht's nun aus? Hat Cavaille recht und es wird immer alles prozessiert?

Würde also bei einer Umwandlung eines Lossless-Formates in ein anderes (z.B. von FLAC nach ALAC, WAV usw.) keine bitgenaue Kopie mehr herausschauen (z.B. beim zurückwandeln nach WAV und Vergleich mit der ursprünglichen WAV-Datei, wie sie z.B. EAC immer zuerst erzeugt)?

Nach meinem bisherigen Wissensstand wird nichts prozessiert oder mit Dithering bearbeitet, innerhalb von Lossless bleibt auch nach 1000 Umwandlungsvorgängen alles bitgenau erhalten.

Greez
Paesc

Cavaille spricht von Editoren, von der Anwendung von Filtern. Wenn du auf ein Audiofile Filter anwendest, werden mit dem Material Berechnungen durchgeführt. Diese sind verlustbehaftet, weil man nur mit endlicher Genauigkeit rechnen kann und weil Filter das Material per definitionem verändern. Wenn du allerdings das File nur in den Editor einlädst und wieder abspeicherst, hast du keine Verluste zu erwarten. Die Files werden bitidentisch sein, jedenfalls bei Wave. Sollten wider Erwarten doch Unterschiede auftreten, dann betrifft das nicht den Datenbereich, in dem die Samples gespeichert sind.
Bitidentität ist allerdings nicht alles, Pelmazo hat es schon erklärt.

Beim Umwandeln von Wave nach Flac und wieder zurück ist die Bitidentität der Waves gewährleistet, sofern beim Dekodieren des Flacs kein Fehler auftritt und du mit dem gleichen Programm arbeitest.

Schau dir mal den Aufbau eines Waves an. Dann schau dir mal ein Wave in einem Hex-Editor an. Verändere ein Bit im Samplebereich so, dass du einen Verlust/Rundungsfehler simulierst. Hör dir das Ergebnis an. Und dann beantworte dir mal die Frage, ob dieser Eiertanz um Bitidentität eigentlich gerechtfertigt ist.;)

Ums mal gleich zu sagen, ich bin kein Gegner der Digitalisierung. Aber man sollte diese auch nicht "vergöttern" und denken, dass ist dann alles ohne Verfälschung und die Perfektion schlechthin. Sicherlich ist alles eine Frage des Berechnungs-Aufwandes und wenn man dies hoch genug betreibt, habe selbst ich nichts mehr zu meckern
Mir ging es ja erst mal ums Prinzip, weil's evt. doch einige Leute nicht so sehen.
Ich habe vor einigen Jahren meine CDs oder Wavs mit WinOnCd-Editor bearbeitet. Da ich mir dieser Zeit dachte, digital ist das Beste was man machen kann, achtete ich auch nicht auch die Details im Signal, sondern nur auf Höhe, Bässe, weggefiltertes Rauschen etc. Später jedoch fiel mir auf, dass alles so seltsam "Glatt" klingt und bei jeder weiteren Nachbearbeitung immer mehr Details verloren gehen. Es reicht da schon nur den EQ Reinzunehmen (alles auf 0) und schon verringert sich die Detailfülle.
Nehme zur Zeit WavLab, aber auch da benutze ich meistens nur EQ1 und versuche alles unnötige zu vermeiden, weil auch dort je nach benutzen Effekten das Rundungs-Problem zu hören ist.
Also ich kann von meiner Seite nur sagen, diese Rundungen sind keines Falles bei 16Bit/SR44,1kHz so gering, dass man sie vernachlässigen könnte. Gut ich habe nun mitbekommen, dass es größere Differenzen zwischen dem Wahrnehmungsvermögen verschiedener Leute gibt und ich wahrscheinlich durch die Vergangenheit jetzt sehr genau hinhöre, aber wir sind ja hier auch im Hifi-Forum.
Ich habe da gleich mal einen Test gemacht.
Original im Vergleich zu 10x EAC Normalisierung 95% zu 98% zu 95%
differences found: 1762334 sample(s), starting at 0.0000000 second(s), peak: 0.0003357 at 0.0126531 second(s), 2ch
Nero-Editor-Analyse (80KB): http://yourfiles.biz/?d=2BB73CF22 120
Man kann da einige Rundungsunterschiede deutlich sehen.

Da hätte ich noch eine Frage:
Was unterscheidet den Signalbearbeitungsprozess eines Editors zu der im System und der Übertragung zur Soundkarte?

deltaalpha66 schrieb:

Es reicht da schon nur den EQ Reinzunehmen (alles auf 0) und schon verringert sich die Detailfülle.

Sorry, aber das ist unglaubwürdig. Sofern der EQ sauber implementiert ist, passiert da nix. Alles auf Null ist dann gleichbedeutend mit Bypass und der Samplebereich im Wave ist dann bitidentisch zum Original.

Dass die Files insgesamt trotzdem nicht bitidentisch sind, kann passieren, nämlich dann, wenn die Waves mit verschiedenen Programmen erzeugt werden. Schreiben beide Programme kanonisches Wave, ist alles OK. Wenn ein Programm aber kein kanonisches Wave schreibt, können die Files ja nicht bitidentsch sein.

Thomas Höss und Tobias Rieck schreiben:

Die meisten wave files sind sehr einfach aufgebaut und können deshalb auch von ``alten ``Programmen verarbeitet werden. Dieses ursprüngliche wave Format wird hier als kanonisches WAV-Format bezeichnet. (Die engl. Bezeichnung canonical wave file format wurde der Beschreibung von tjw entnommen) Heutzutage, macht es jedoch einen schlechten Eindruck wenn eine Software geschrieben wird, welche nur dieses Format unterstützt. Eine Software kann beim lesen eines RIFF files alle chunks, welche sie nicht versteht, ignorieren. Beim schreiben sollten diese chunks aber wieder in das neue file eingefügt werden, wodurch die Software mindestens die voneinander abhängigen chunks verstehen muss.

Siehe auch: http://www.it.fht-es...00/HTML/node107.html

Diese Bemerkung mit dem "EQ alles auf 0 ..." galt speziell für WinOnCD (Es war zumindest mein Eindruck). Dort kann man es aber nicht prüfen, weil es Unterschiede in der Filelänge gibt, ansonsten hab ich das mal bei anderen Programmen geprüft, da sind die Files bitidentisch zum Original.

Wie ist das jetzt mit meiner Frage ...?

deltaalpha66 schrieb:

Wie ist das jetzt mit meiner Frage ...?

ich hab auch mal eine frage!

welche kopfhörer benutzt du?

hatte auch schon mal nach equip gefragt.

welchem KH oder LS?

Die Kopfhörer gibt es so nicht im Handel. Ich habe meine Funkkopfhörer von Nasaco 433HP umgebaut und kann jetzt wahlweise Kabel oder Funk benutzen.
Natürlich benutze ich Kabel für Tests. Ich hatte aber auch schon andere probiert, keiner hatte bisher diesen speziellen (inzwischen mir teuer gewordenen) Klang.

12search schrieb:

Cavaille spricht von Editoren, von der Anwendung von Filtern. Wenn du auf ein Audiofile Filter anwendest, werden mit dem Material Berechnungen durchgeführt. Beim Umwandeln von Wave nach Flac und wieder zurück ist die Bitidentität der Waves gewährleistet, sofern beim Dekodieren des Flacs kein Fehler auftritt und du mit dem gleichen Programm arbeitest.

Das klingt sehr beruhigend. Also ist auch nach 1000 Wandlungen von einem Lossless-Format ins andere die Bitidentität gewährleistet, sofern keine Fehler auftreten. Einzig durch Bearbeitung können also Fehler auftreten. Fragen hierzu:

1. Wenn ich ein Ein-/Ausblenden (Fade in/Fade out) durchführe, wird dann die ganze Musikdatei bearbeitet (z.B. Dithering)?
2. Schneiden und Zusammenfügen, bewirkt das auch Veränderungen? Teilen wohl weniger, glaube ich. Beim Kombinieren bin ich mir weniger sicher.

12search schrieb:

Schau dir mal den Aufbau eines Waves an. Dann schau dir mal ein Wave in einem Hex-Editor an.

Das geht mir ein bisschen zu weit, kenne ich noch nicht. Hex-Editor? Welche Programme hierzu gibt es?

@deltaalpha66: Kenne Deinen Kopfhörer nicht, noch nie was von Nasaco 433 HP gehört. Habe gerade nachgesehen, es scheint sich bei Nasaco um einen Kommunikationsspezialist zu handeln - keinen Hersteller, der auf hochwertige Hörer ausgerichtet ist. Ein Muss für gute Hörtests sind Kabelhörer, mit Hörern von Sennheiser, AKG und Grado liegt man fast immer gut, sehr empfehlenswert.

Greez
Paesc

@Paesc schrieb:

Das geht mir ein bisschen zu weit, kenne ich noch nicht. Hex-Editor? Welche Programme hierzu gibt es?

ich benutze für hex immer noch den guten alten hexworkshop 3.11
is ziemlich leicht zu bedienen.



zu dem Nasaco teil:

würd ich auch sagen lieber nen KH mit kabel.

es könnt ja sein das was ins funksignal reinkommt(bei billigKH leicht möglich) und sich bei dir die musi dadurch immer anders anhört.

deltaalpha66 schrieb:

Diese Bemerkung mit dem "EQ alles auf 0 ..." galt speziell für WinOnCD...

Ich hoffe, du verstehst mich nicht falsch. Ich glaube dir das durchaus. Allgemein gültig dürfte das aber nicht sein. Dass es Programme gibt, welche die Daten trotz Nullstellung verändern, negiert meine Aussage ja nicht. Professionellere Softwarelösungen dürften dem Anwender da sämtliche Freiheiten lassen, so dass er das Verhalten des Programms sehr genau steuern kann. Es ist einfach unplausibel, dass ein Programm die Daten bei Nullstellung verändert.

Paesc schrieb:

Einzig durch Bearbeitung können also Fehler auftreten

Hier von Fehlern zu sprechen, ist meiner Meinung nach nicht ganz richtig. Man will die Daten ja verändern.

Paesc schrieb:

Wenn ich ein Ein-/Ausblenden (Fade in/Fade out) durchführe, wird dann die ganze Musikdatei bearbeitet (z.B. Dithering)?

Wenn das Programm was taugt, dann werden nur die bearbeiteten Teile einer Berechnung unterzogen.

Paesc schrieb:

Schneiden und Zusammenfügen, bewirkt das auch Veränderungen? Teilen wohl weniger, glaube ich. Beim Kombinieren bin ich mir weniger sicher.

Schneiden und Zusammenfügen bewirkt keine Veränderungen im Samplebereich. Nur der Dateiheader wird verändert. Beim Zusammenfügen sollten die Files die gleichen Parameter hinsichtlich Samplerate, Channels usw. aufweisen. Es gibt aus meiner Sicht keinen plausiblen Grund, warum das nicht so sein sollte. Audacity macht es jedenfalls richtig.

Nimm die Aufforderung mit dem Hex-Editor mal nicht so wörtlich. Das sollte dir nur aufzeigen, dass man die ganze Angelegenheit auch etwas entspannter sehen kann. Das Wörtchen Verlust wird regelmäßig überbewertet.

Paesc schrieb:

Kenne Deinen Kopfhörer nicht, noch nie was von Nasaco 433 HP gehört. Habe gerade nachgesehen, es scheint sich bei Nasaco um einen Kommunikationsspezialist zu handeln - keinen Hersteller, der auf hochwertige Hörer ausgerichtet ist. Ein Muss für gute Hörtests sind Kabelhörer, mit Hörern von Sennheiser, AKG und Grado liegt man fast immer gut, sehr empfehlenswert.

Diese KH stammen aus den 90ern, wo die ersten 433MHz-Analog-KH auf den Markt kamen. Ich bin recht froh, diese durch mehrmalige mechanische Rettungsaktionen bis in die heutige Zeit erhalten zu haben. Solange ich damit noch mehr als andere Leute hören kann und die Dinger nicht endgültig auseinander fallen, bin ich damit vorerst recht zu frieden. Ohne meine spezielle Funk/Kabel Umschaltlösung wäre diese wohl nicht mal die Hälfte wert.

Jetzt mal eine andere Sache:
Wenn ich Winamp nehme, DSP für irgendeine (aufwendigere) Klangbearbeitung aktiviere (Einstellungen so, dass nicht gerade Null ist)
(evt. sogar mit "MuchFX²" mehrere DSPs verwenden würde)
Output: Nullsoft Disk Writer
Würde die Signalverarbeitung wie die eines Editors stattfinden, oder wäre es schon zur Hälfte der Signalweg, wie die des normalen Abspielens einer Datei?

die frage klingt schon irgendwie abgefahren.

ich bearbeite alle musikdatein mit wavelab, wen sie fertig ist mit 224kbs kodiert.

winamp is ein player, Nullsoft Disk Writer schreib die datei nur wieder in wav auf die platte.

wie soll die bearbeitung mit winamp funktionieren???????

was willst damit erreichen?

ich schalte winamp oder nen anderen player an, nem ne hochkodierte mp3(über 192) und gut is es.

wenn du dir bessere KH kaufst, wirst glücklicher, als 3 jahre probieren aus ner lausigen mp3 was rauszuhohlen.

Die Frage hat einen bestimmten Hintergrund.

Ok finden wir es raus mit einem Test:
Winamp 5x den gleichen File (mit DSP) schreiben lassen und jeweils den wav 1-5 bezeichnen
die Files untereinander mit Bit-Compare vergleichen
Wie sind Eure Ergebnisse?

alles gleich was nun????(ich nehme natürlich meine doofe 2.91 version)
hier:
http://img514.imageshack.us/my.php?image=vergleich11cg1.jpg

Das ist wahrscheinlich unter Umständen bei jedem (oder jedes mal) anders.

Mit DSP "QM 2105 Filter Module" Gestern hatte ich 5 Unterschiedliche Files, heute ist nur der 1. anders 2-5 zueinander identisch
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav1.wav"
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav2.wav"
differences found: 485101 sample(s), starting at 0.0000000 second(s), peak: 1.9999695 at 0.1041950 second(s), 2ch

Versuch 2 Winamp neu gestartet mit DSP "Wide & Dynamix"
Comparing:
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav1.wav"
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav2.wav"
differences found: 953775 sample(s), starting at 0.0000000 second(s), peak: 0.2934570 at 0.1326077 second(s), 2ch
Comparing:
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav2.wav"
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav3.wav"
differences found: 807006 sample(s), starting at 0.0000227 second(s), peak: 0.0097961 at 8.8459637 second(s), 1ch
Comparing:
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav3.wav"
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav4.wav"
differences found: 840606 sample(s), starting at 0.0015193 second(s), peak: 0.0095825 at 17.0483220 second(s), 1ch
Comparing:
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav4.wav"
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav5.wav"
differences found: 810037 sample(s), starting at 0.0010658 second(s), peak: 0.0087891 at 0.6345125 second(s), 2ch

Man beachte, dass es manchmal nur ein Kanal ist!

Versuch 3 Winamp neu gestartet mit DSP "Enhanger ! v0.1.4"
Comparing:
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav1.wav"
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav2.wav"
differences found: 142216 sample(s), starting at 0.0000000 second(s), peak: 0.6994934 at 0.0001361 second(s), 1ch
2-5 identisch

Vielleicht können noch mal ein paar andere Leute den Test machen. (am besten jedesmal vor dem Test Winamp neu starten)

Nanu, was ist los, hat da keiner eine Meinung oder Erklärung dazu?
Wie sieht es aus, hat mal jemand den Test auf seinem Rechner gemacht?

Habe heute mal ein aktuelles angebotenes DSP von MPEX runtergeladen:
"Jamix Enhancer" Preset: "Studio Headphones" Config: Delay: 1000ms (Autodetect: Aus)
Windows XP, SP2, keine weiteren Updates, ZoneAlarm Aktiv (Antivirus+Firewall)
5x schreiben lassen und jeweils den wav1-5 bezeichnet

Anlyse mit Foobar2000 / Bit Compare:
Comparing:
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav1.wav"
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav2.wav"
differences found: 1700312 sample(s), starting at 0.0000000 second(s), peak: 0.4821777 at 0.0027211 second(s), 2ch
Comparing:
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav2.wav"
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav3.wav"
differences found: 1605283 sample(s), starting at 0.0000000 second(s), peak: 0.0702515 at 19.1136961 second(s), 2ch
Comparing:
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav3.wav"
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav4.wav"
differences found: 1603026 sample(s), starting at 0.0000227 second(s), peak: 0.0733032 at 4.2620181 second(s), 2ch
Comparing:
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav4.wav"
"D:\temp\01_14 - Michael Jackson - Billie Jean orig_wav5.wav"
differences found: 1609075 sample(s), starting at 0.0000000 second(s), peak: 0.0757751 at 13.2268027 second(s), 1ch

Hallo,

schau mal hier:http://www.winamp.com/plugins/details/147820

Ich zitiere:

High quality DSP Simple to use yet it's really effective and configurable whether you're into slight or full on tweaking of your listening experience.Solidly put together and works really well. Also if you've experienced issues with this in the past with newer versions of Winamp, then this is the version you will need! Only quirk is that the preset selection doesn't seem to hold it's state correctly when selected otherwise spot on.

Der letzte Satz ist interessant.

Starte Winamp bei jedem Mal neu und nimm identische Einstellungen vor. Dann sollten die Ergebnisse identisch sein.

Ja ich habe es überprüft, die ersten Wavs nach dem Winamp-Start sind identisch (sehr eigenartig). Ansonsten treten ja diese Abweichungen auch bei anderen DSPs auf, aber es scheint nicht die Art Verfälschung im System zu sein, für die ich es erst hielt.
Gleich mal eine Frage: Weiß jemand, wie die Signale im System-Mixer gemischt werden?
Dies dürfte doch wohl digital sein und dann erst in der Summe zu Analog gewandelt werden. Das heißt, wenn ich über StereoMix aufnehme und alle überflüssigen Inputs ausschalte, dann sollte kein Analog(Stör)signal in die Aufnahme einstreuen können.
Oder sehe ich das falsch?

@12search

thx,netter dsp.

ne frage dazu, setzt der das mad-plugin ausser gefecht?

Mad ist ein Decoder, oder?

Einfache Überlegung: Ein DSP wird grundsätzlich auf das dekodierte Signal angewandt. Wäre das nicht so, müßte ja jedes DSP-Plugin einen eigenen Decoder integriert haben. Dem wird wohl nicht so sein.

Folglich dürfte es so aussehen: Mp3 > Decoder > DSP

Die Antwort wäre also Nein. Wenn ich falsch liege, berichtigt mich.

hab bishen rumprobiert das plugin läuft weiter.

Gerade habe ich etwas entdeckt: Wollte nur mal aus Routinegründen meine Matrix-MP3s mit CBR 192kbps mit denen ohne Matrix komplett vergleichen.
Test1: alle identisch bis auf Foolsgarden
Comparing:
D:\temp\Test-RAR\Test 1 - Lame3.90.3 CBR Matrix 008-192kbps-Neu\Lame3.90.3 stereo 192kbps (SR44kHz -b 20kHz)\08 - Foolsgarden - Lemon Tree.mp3
D:\temp\08 - Foolsgarden - Lemon Tree.mp3
differences found: 7706 sample(s), starting at 4.4812018 second(s), peak: 0.0098992 at 4.5031973 second(s), 1ch
Man beachte: in diesem Fall nur ein Kanal!
Habe das jetzt genau geprüft. Da ich teilweise auf AMD und Pentium gearbeitet hatte, wurde ich fündig. Die Abweichung tritt bei der Enkodierung auf AMD zu Pentium bei bestimmten Signalkonstellationen auf.
Alle bei Test1 im Download enthaltenen Matrix-192kbps-CBR's sind auf einem Pentium-Notebook gemacht worden. Wer einen AMD hat, kann dies nachprüfen, mit meiner oben angegebene Zeile encodieren und vergleichen. (Alle anderen wurden allerdings komplett auf AMD encodiert)
Dies lässt nun aber vielleicht doch die Möglichkeiten offen, dass es auch Files gibt, wo die Matrix Einfluss auf das Ergebnis hat.

@deltaalpha66

wiso machst es nicht wie die anderen leute?
mach wenn dir 192kbs auch zu wenig ist, 224kps mp3's und hab einfach spass an der musik.


das alles was du schreibst wird sowieso nie zu etwas führen!!! (ist nicht böse gemeint)

Kann lorenz4510 nur zustimmen...

Wann kommst Du eigentlich noch zum Musik hören?! Habe den Eindruck, dass Du wesentlich mehr Zeit mit Fehlersuche und Entfernen von vermeintlichen Ungereimtheiten verbringst.

Überlege Dir mal folgendes: Es gibt auf der ganzen Welt Millionen von Leuten, welche tagtäglich ihre Musik geniessen und Spass daran haben. Willst Du nicht auch dazugehören, weniger Zeit mit (Matrix-)Tests und mehr Zeit mit Genuss zubringen? Im "Zweifelsfalle" gibt es ja auch für Dich noch immer die altbekannten, zigfach bewährten Anleitungen zur File-Erstellung mit EAC und Foobar2000:

EAC-Anleitung: http://www.audiohq.de/index.php?showtopic=47
Foobar2000-Anleitung: http://www.audiohq.de/index.php?showtopic=13

Damit ist Genuss garantiert: die Datenrate und das Format kann man ja selber auswählen... Die Empfehlungen sind in den Anleitungen bereits genannt. Mit einem Lossless-Format wärst Du schon längst über jegliche Zweifel und Ausmasse von Verlusten der Komprimierung hinweg und würdest erhaben auf Lossy-Verluste herablächeln

Greez
Paesc

Es geht mir in diesem Falle zunächst gar nicht allein um einen hörbaren Unterschied bei MP3. Allein die Tatsache, dass sich das Encodieren doch von äußeren Faktoren beeinflussen lässt, ist doch von größter Bedeutung!
Habe jetzt mal eine Stichprobe aus meinem Test- und CD-Archiv gemacht, der erste File - Volltreffer!:
Comparing:
M:\N192kbsN Lame 3.90.3 Pentium\The Best Of 1980-1990 Vol.11 - CD2+\06 - Propaganda - Heaven Give Me Words.mp3
M:\N192kbsN Lame 3.90.3 AMD\06 - Propaganda - Heaven Give Me Words.mp3
differences found: 35865 sample(s), starting at 45.2061225 second(s), peak: 0.0411218 at 45.3307937 second(s), 2ch

Das wirft natürlich neue Fragen auf:
wie z.B.: was ist besser, Pentium oder AMD, wie groß ist der Einfluss wirklich und ist dieser unter Umständen hörbar...? Ich habe allerdings auf die Schnelle nichts genaues feststellen oder raushören können. Glaube auch nicht dass dies bei VBR nicht passiert, dort stört mich aber noch einiges anderes. Meine Blindhörtests waren ja wohl aussagekräftig genug.

Wer meint, das geht mich alles nichts an, denn ich nehme flac...
Was ist den mit den immer wieder beschriebenen Codierungsfehlern?
Vielleicht sind aber diese Fehler bei flac genau aus den gleichen Gründen vorhanden, nämlich den Einflüssen von außen (z.B. Datenstrom- o.a. Systemeinflüsse) und/oder besonderen bzw. extrem sprunghaften Dynamikwerten!
Falls dies bei Flac zutrifft, könnte ich theoretisch mit meiner Matrix das Ganze so stabilisieren und eben derartige Fehler (bzw. sogar falls auch bei anderen Formaten vorhanden, da ebenso) weitestgehend unterbinden.

deltaalpha66 schrieb:

Wer meint, das geht mich alles nichts an, denn ich nehme flac... Was ist den mit den immer wieder beschriebenen Codierungsfehlern?

Die Frage gebe ich zurück. Welche Fehler meinst du konkret?

Wie immer ignorierst Du gut gemeinte Tipps und Meinungen anderer. Schade, ich hoffe, dass auch Du irgend wann Musik zu geniessen beginnst und nicht dauernd etwas messen, verändern usw. musst.

deltaalpha66 schrieb:

Es geht mir in diesem Falle zunächst gar nicht allein um einen hörbaren Unterschied bei MP3. Allein die Tatsache, dass sich das Encodieren doch von äußeren Faktoren beeinflussen lässt, ist doch von größter Bedeutung! Habe jetzt mal eine Stichprobe aus meinem Test- und CD-Archiv gemacht, der erste File - Volltreffer!: Comparing: M:\N192kbsN Lame 3.90.3 Pentium\The Best Of 1980-1990 Vol.11 - CD2+\06 - Propaganda - Heaven Give Me Words.mp3 M:\N192kbsN Lame 3.90.3 AMD\06 - Propaganda - Heaven Give Me Words.mp3 differences found: 35865 sample(s), starting at 45.2061225 second(s), peak: 0.0411218 at 45.3307937 second(s), 2ch

Keine Ahnung was Du nun schon wieder angestellt hast, bei ordnungsgemässer Erstellung einer MP3-Datei sollte das nicht vorkommen – zumindest nicht häufig.

deltaalpha66 schrieb:

Das wirft natürlich neue Fragen auf: wie z.B.: was ist besser, Pentium oder AMD, wie groß ist der Einfluss wirklich und ist dieser unter Umständen hörbar...? Ich habe allerdings auf die Schnelle nichts genaues feststellen oder raushören können. Glaube auch nicht dass dies bei VBR nicht passiert, dort stört mich aber noch einiges anderes. Meine Blindhörtests waren ja wohl aussagekräftig genug.

Nein, bei dem Thema waren wir doch schon mal. Bei Dir hat anscheinend so ziemlich jedes Bauteil und jede Schwingung einen Einfluss auf das Ergebnis... Wobei wir wieder bei den Wasseradern, Energiequellen, Räucherstäbchen im PC und Uriellas ultimativ heilbringendem Badewasser wären. Voodoo lässt grüssen. Scheint sich alles zu wiederholen…

deltaalpha66 schrieb:

Wer meint, das geht mich alles nichts an, denn ich nehme flac... Was ist den mit den immer wieder beschriebenen Codierungsfehlern?

Sollte, wie oben erwähnt, nicht vorkommen. Ansonsten: hat jemand, der hier mitliest, schon grössere Probleme mit Lossless-Codecs gehabt? Falls ja gehe ich doch sehr davon aus, dass das eher eine Seltenheit ist. Gerade FLAC ist sehr stabil.

deltaalpha66 schrieb:

Vielleicht sind aber diese Fehler bei flac genau aus den gleichen Gründen vorhanden, nämlich den Einflüssen von außen (z.B. Datenstrom- o.a. Systemeinflüsse) und/oder besonderen bzw. extrem sprunghaften Dynamikwerten! Falls dies bei Flac zutrifft, könnte ich theoretisch mit meiner Matrix das Ganze so stabilisieren und eben derartige Fehler (bzw. sogar falls auch bei anderen Formaten vorhanden, da ebenso) weitestgehend unterbinden.

FLAC ist verlustlos, im Normalfall geht kein einziges Bit verloren! Da wird mir wohl jeder, der hier mitliest, zustimmen, oder?

Greez
Paesc

Hallo Deltaalpha66,

hatten die Computer vielleicht verschiedene Farben? Ich glaube, daran könnte es liegen. Mal messerscharf nachgedacht... ja! ... das ist die Lösung!

Ich verstehe es nicht. Oben hast du doch schon eingeräumt, dass deine Matrix nur Dünnes ist. Jetzt versuchst du wieder, ihr doch noch irgendwie, auf Biegen und Brechen eine Wirksamkeit anzudichten. Völlig egal, woran es tatsächlich liegt, die Lösung kann nur deine Matrix sein. Ich bitte dich...

Du schreibst selbst, du hättest keine Ahnung. Wie entwickelst du eigentlich? Wie optimierst du?

Eigentlich ist es ein Wunder, dass du es schaffst, den Computer hochzufahren und hier deine Postings abzusetzen. Oder hast du nebenbei auch hier deine Matrix laufen, um den Datenströmen die gebotene Stabilität zu verleihen? Den Mitlesern kommt hier regelmäßig die Galle hoch, vertrau mir.

Ach, und welche Kodierungsfehler meinst du? Du versuchst hier, auf Teufel komm raus irgendwelche Unsicherheiten zu generieren. Was soll der Mist? Du verursachst nur Mehrarbeit für diejenigen, die versuchen, das wieder richtigzustellen.

Wenn es dich interessiert, beschäftige dich mit den Grundlagen. Digitale Signalverarbeitung, Nachrichtentechnik und weiß der Geier, was noch. Lerne Programmieren. Kurz, nutze deine Zeit sinnvoll. Dann kannst du später, nach drei Jahren vielleicht, tatsächlich irgendwas reißen.

Das hier ist ein öffentliches Forum, kein Chat. Die Informationen/Postings werden auch in einigen Jahren noch abrufbar sein. Das solltest du dir immer vor Augen halten, wenn du hier dein Esoterik-Zeug abwirfst. Es ist einfach nur grausam...

*no offense*

Vielleicht liegt es am Standort der Computer. Sonneneinstrahlung, Stellung der Gestirne und die Energieabgabe von Mutter Erde beeinflussen insbesondere digitale Signale enrom... Sorry, etwa so hören sich die Aussagen von deltaalpha66 an. Man weiss nicht, woher es kommt aber es ist ganz sicher da...

Einen wesentlichen Punkt hat 12search bereits angesprochen. Dieser Thread wurde aktuell 1814 mal angeklickt. Wenn nun andere durch das, was deltaalpha66 schreibt, verunsichert werden, folgen garantiert früher oder später neue Threads mit Fragen oder vermeintlichen Feststellungen, die rein subjektiver Natur sind.

Schliesslich muss ja ein Unterschied stattfinden: verschiedene Windows-Ausgaben machen mit gleicher Encodierungssoftware anderen Klang, der Prozessor hat evtl. Einflüsse, die Grafikkarte verursacht auch immense Unterschiede usw... Es scheint doch sehr, als würden Einflüsse und Unterschiede regelrecht gesucht! Sorry, wenn beim Encodieren derart viele und eindeutige Unterschiede auftreten würden, würde die ganze Kiste laufend abstürzen, weil dann auch andere Anwendungen dauernd versagen würden. Einfach mal ein Bit dazu, mal eins Weg, mal ein wenig anders ist in der Digitaltechnik absolut unverzeilich! Angenommen, ich hätte ein mit 128 Bit verschlüsseltes Passwort mit 100 Zeichen, reicht ein einziges falsches Zeichen, um den Zugang zu verweigern. Ein Bit reicht vollkommen aus, geschweige denn von einem ganzen Byte...

Naja... Wie bereits gesagt: ich verweise auf die Anleitungen zu EAC und Foobar2000 bei AudioHQ. Bei damit erstellten Files treten nicht dauernd urkomischen Unterschiede auf, die keinen erklärbaren Grund haben sollen. Irgend etwas machst Du falsch. Halte Dich bitte an über Jahre bewährte Methoden. Sollten wirklich so viele Unterschiede und Fehler auftreten, wie Du sie nennst, wäre dies längst ein riesiges Thema in Fachkreisen.

Greez
Paesc

Was an dem von mir belegten Beispiel versteht Ihr nicht, dass sich der Encodierungsprozess hier in einem Fall der File "Foolsgarden" beim Pentium zum Athlon unterscheidet oder beeinflussen lässt? Warum hat das keiner geprüft, oder hat dafür jemand eine Erklärung?
Dies tritt aber speziell bei bestimmten dynamischen Konstellationen wie in dem Fall Glasscherbengeräusch auf. Ich halte das für kein Zufall. Weiter vergrößert sich das Problem, je länger die Files werden! Wenn ich mir mal demnächst etwas Zeit nehme, werde ich dies genauer untersuchen.



Beispiele für beschiebene Fehler mit flac aus diversen Foren:

Resultat nach dem Rippen ist dann Knirschen, Rauschen etc. in der Flac-Datei. Wobei in CDEx keine Fehler angezeigt werden. Ich dachte zunächst dass die Fehler beim Rippen auftreten und der Datenstrom zwischen DVD-Laufwerk und Festplatte gestört wird. Allerdings treten auch bei nachweislich einwandfreien Flac-Dateien ( habe sie auf meinem Laptop zum Test abgespielt ) Fehler auf wenn ich sie ( mit dem CDex-Player, da kein Winamp installiert ) abspiele und nebenher etwas Last erzeuge - insofern gehe ich mittlerweile davon aus dass die Fehler erst beim kodieren entstehen. Das kann doch eigentlich nicht Sinn der Sache sein - immerhin handelt es sich um einen PC der hardwaretechnisch locker ausreicht ( Sempron 2400+, 512 MB RAM ). Hat jemand eine Idee woran es hängen könnte und vor allem wie ich diesen "Bug" behebe? Es stört massiv nach jedem Rippen die Ungewissheit zu haben ob auch wirklich alle Tracks einwandfrei kopiert wurden...

http://www.silverjuke.net/forum/topic-1876.html

Habe gerade richtig tolle Erfahrungen mit dem Flac-Codec gemacht. Meine ganzen Dateien die ich von Schallplatten in liebevoller Kleinarbeit digitalisiert habe sind im Eimer ! Der Flac Codec hat anscheinend ein Problem mit großen Dateien oder sonst was. ( hatte den FLAC 1.1.4 benutzt ) Nach dem Umwandeln in Flac konnte Silverjuke die im Ganzen aufgenommenen Schallplattenseiten nicht mehr abspielen und jetzt nach dem zurückwandeln in .wav ist nur noch Datenmüll in den Dateien . Die drei vier Platten die ich vorher schon zu einzelnen Titeln geschnitten hatte funktionieren tadellos , der Rest ist Schrott. (Das war die Arbeit von einem halben Jahr ) Was ich in diesem Moment von Flac halte, spare ich mir lieber.

http://www.deejayfor...ergleichstest-3.html

Da kanst Du auch gleich den WAV abspeichern. Flac ist max. 1/3 kleiner. Bei den heutigen Speicherpreisen fällt es auch nicht mehr ins Gewicht. Außerdem braucht man die Datei nicht auf Kodierungsfehler zu prüfen.

Ist Dir etwas aufgefallen, wenn Du die Berichte über fehlerhafte FLAC-Files gelesen hast? Es wurde immer die Version 1.1.4 verwendet. Siehe hier zur bekannten Problematik mit Version 1.1.4: http://www.audiohq.de/index.php?showtopic=2207

Ich hatte bisher keine einzige FLAC-Datei, die auf irgend eine Art beschädigt oder fehlerhaft ist. Ist bei vielen anderen Nutzern bestimmt auch der Fall. Ich verwende Version 1.2.0, zuvor 1.1.4. So, nun ist der gute Ruf von FLAC hoffentlich wieder hergestellt...

deltaalpha66 schrieb:

Was an dem von mir belegten Beispiel versteht Ihr nicht, dass sich der Encodierungsprozess hier in einem Fall der File "Foolsgarden" beim Pentium zum Athlon unterscheidet oder beeinflussen lässt? Warum hat das keiner geprüft, oder hat dafür jemand eine Erklärung?

Wie schon x-mal gesagt: Deine Probleme stellen nicht die Norm dar. Ich habe keine Erklärung dafür. Aber es ist nicht sehr wahrscheinlich, dass Fehler oder "Beeinflussungen seitens Prozessor" an Intel oder Athlon liegen. Das würde ja auf alle anderen Anwendungen auch zutreffen und somit andauernd schwerstwiegende Fehler (unter anderem Komplettabstürze) verursachen. Du bist ja auch der Meinung, verschiedene Windows-Ausgaben klängen anders... Ohne genauer darauf eingegangen zu sein oder tiefgreifendere Erläuterungen zu liefern. Aber lassen wir das.

Edit:
Dir sind offensichtlich gewisse Grundlagen der Digitaltechnik nicht gläufig. Ich besitze zwar auch keine vertiefte Ausbildung im Zusammenhang mit Digitaltechnik, aber was ich mit Sicherheit weiss: Ein Prozessor macht nicht einfach mal ein paar Bits mehr oder weniger, mal etwas anders. Es kann nicht sein, dass ein Intel- und ein AMD-Prozessor mit der gleichen Software (z.B. Foobar2000) oftmals andere Ergebnisse liefert und ansonsten absolut stabil läuft. Da ist was faul. Denn dann müssten auch in anderen Bereichen und mit anderen Programmen andere Bits und somit Fehler auftreten, was zu Instabilitäten/Abstürzen des Systems führt. Und wie verschiedene Windows-Ausgaben anders "klingen" sollen, ist mir ohnehin schleierhaft... Aber da Du lange mit Onboard-Audio mit verlustbehaftetem Realtek AC97 gearbeitet hast, wundert das mich nicht. Dass Du dann auch noch einen alten Funkkopfhörer eines Kommunikationsspezialisten mit Kabeln nachgerüstet hast, passt da irgendwie ins Bild.

Was soll ich da bitte überprüfen? Fehler herbeizaubern, die nicht da sind, da bei mir bisher dummerweise alles reibungslos läuft? Was soll den Encodierungsprozess "beeinflussen" (oder sagen wir besser: Fehler produzieren)? Welche Software brauchst Du, um bei Deinen Files zu testen, ob sie bitidentisch sind? Vielleicht geschieht da ein Fehler/falsche Einstellung...

Greez
Paesc

Paesc schrieb:

Ich hatte bisher keine einzige FLAC-Datei, die auf irgend eine Art beschädigt oder fehlerhaft ist. Ist bei vielen anderen Nutzern bestimmt auch der Fall. Ich verwende Version 1.2.0, zuvor 1.1.4. So, nun ist der gute Ruf von FLAC hoffentlich wieder hergestellt...

Mag sein, dass es an früheren flac-Versionen gelegen hat (auch da hätte das nicht passieren dürfen), wir werden sehn ob es weitere Fehlerberichte aus diesem Bereich gibt. Habe mal noch etwas im Netz gesucht, die Fehler bei Flac u.a. Formaten sind wohl doch nicht so selten, immerhin gibt es Software um diese zu finden...
http://www.netzwelt....er-ueberpruefen.html

Bei Flacs wird beim encoden eine Prüfsumme des Audiostreams (ohne Header Dateien) erstellt, um später überprüfen zu können ob die Dateien fehlerfrei sind. Dies geht ganz einfach mit dem Tool. Einfach installieren, dann mit der rechten Maustaste auf den zu überprüfenden Ordner klicken und "verify with md5check" anwählen. Danach öffnet sich ein Dos Fenster und die Datein werden überprüft und am Ende wird auch eine kurze Zusammenfassung gezeigt.

http://www.mpex.net/news/archiv/00769.html

AudioTester: Fehlersuche für MP3, Ogg Vorbis, FLAC, WavPack (MPeX.net/DB - 29.07.2007) - Gleich mehrere Audioformate prüft AudioTester auf Fehler. Das kleine Freewareprogramm scannt Musikdateien in den Formaten MP3, Ogg Vorbis, FLAC sowie WavPack und meldet Fehler im Datenstrom oder den Tags. Die Bedienung ist einfach: Dateien oder ganze Ordner werden per Drag'n Drop, also mit gedrückter linker Maustaste, in das Programmfenster gezogen. Alternativ lässt sich AudioTester auch per Kommandozeile ausführen. Das Ergebnis der Analyse wird für jede Datei separat und als Zusammenfassung angezeigt. Leider fehlt eine ausführliche Dokumentation der Fehlermeldungen. Trotzdem bietet sich AudioTester als Hilfsmittel an, wenn Probleme bei der Wiedergabe oder der Bearbeitung von Audiodateien auftauchen.

Um noch mal auf die Unterschiede mit Lame3.90.3 bei Athlon und Pentium zurück zu kommen:
Ich hatte schon mitgeteilt, dass ich Foobar2000 mit "Bit-Compare" zur Prüfung benutze.

Paesc schrieb:

Deine Probleme stellen nicht die Norm dar. Ich habe keine Erklärung dafür. Aber es ist nicht sehr wahrscheinlich, dass Fehler oder "Beeinflussungen seitens Prozessor" an Intel oder Athlon liegen

Nur weil Du keine Erklärung dafür hast, heißt dies nicht automatisch, dass es keine gibt! Ich bin sicher es gibt eine (nicht esoterische) logische Erklärung, aber diese könnte auf unterster Rechner-Ebene (vielleicht im binären Bereich) liegen.
Fakt ist (habe dies extra noch mal geprüft), Foolsgarden ist bei 192kbs auf zwei verschiedenen Athlon-Rechnern (XP3200+ Tower-PC / 2500-mobile AMD-Notebook) bit-identisch und ebenfalls auf jeweils der beiden Notebooks (Pentium 3GHz / 600MHz) egal welches BS.
Nicht aber AMD zu Intel!:
Comparing:
D:\temp\Test\Test 1 - 192kbs Athlon 3200+ WinXP\08 - Foolsgarden - Lemon Tree.mp3
D:\temp\Test\Test 1 - 192kbs Pentium 3.0GHz WinXP\08 - Foolsgarden - Lemon Tree.mp3
differences found: 7706 sample(s), starting at 4.4812018 second(s), peak: 0.0098992 at 4.5031973 second(s), 1ch
Wieso ist das also mein Problem? Dies stellt einen klaren Beleg dafür dar, dass es eben Dinge gibt, welche man mit normalem "digitalem Verständnis" nicht so einfach erklären kann.
Hier noch mal neu encodiert Download "Foolsgarden - Lemon Tree" (Pentium+Athlon) und bit-compare für Foobar2000 (1MB):
http://yourfiles.biz/?d=0F18678515
Was hindert also die Pentium oder AMD-Besitzer meinen Test-Wav "Foolsgarden" mit der Zeile [ -b192 -q2 --lowpass 19500 -X0 --scale 0 -mj ] mit Lame3.90.3 zu encodieren und dann mit jeweils dem Test-File (oder noch besser wer beides hat eben direkt) über Foobar/Bit-Compare zu vergleichen? Alle anderen Files sind ja bit-identisch!
Wenn dies dann mal jemand gemacht hat ..., können wir uns vielleicht darauf einigen, dass es eben manchmal solche ungeklärten Dinge gibt? (Oder ziehst Du es vor, die Sache trotz dieser Fakten weiter zu bestreiten?)

Anmerkung:
Verschiedene BS haben allerdings bisher keine Unterschiede im Enkodier-Ergebnis der MP3s gezeigt (dieser Eindruck ist wohl früher meinerseits durch Verwendung Intel und AMD entstanden).

Mensch deltaalpha66, Du hast mir die Erleuchtung gebracht! Es liegt natürlich am Prozessor, was sonst... AMD und Intel erstellen natürlich ganz andere Files, obwohl jeweils exakt die gleichen Programme und Versionen verwendet werden (hoffe, Du hast darauf geachtet). Natürlich betrifft dies nur die Encodierung von Audiodateien, alle anderen Programme sind nicht davon betroffen. Schliesslich würden dann teils üble Fehler daraus erfolgen. Oder halt, vielleicht werden ja Foto-, Video-, Text- und Powerpoint-Dateien auch unterschiedlich gross...

Letzthin habe ich entdeckt, dass Files, welche um Mitternacht bei Vollmond erstellt werden, besonders toll sind. Ich hatte den Eindruck, ein leises Heulen eines Werwolfs und das Pfeifen eines Vampirs zu hören. Echt cool und gruselig! Ach ja, natürlich ist es auch unbedingt zu empfehlen, den PC mit Weihwasser zu übergiessen (der Prozessor muss natürlich auch übergossen werden). Das beseitigt böse Einstreuungen und Störungen, künftig werden sie sich auch nicht mehr so schnell einmisten. Nach 6 Monaten wiederholen. Zur Not kann man auch mit Knoblauch, Silber usw. den PC bearbeiten, so dass Vampire nicht an den Buchsen nuckeln können. Ach ja, den PC nach den Regeln von Feng Shui ausrichten. Hilft enorm. Wasseradern spielen auch eine grosse Rolle. Im Sommer wennmöglich keine Files erstellen, die mögen es lieber kühl und dunkel. Oh, noch was: vielleicht gibt es ja viel bessere Files, wenn man den Prozessor streichelt und knuddelt! Vielleicht war das bei Deinen Intel- oder AMD-Prozessoren so. Die brauchen auch Liebe. Geschweige denn, wenn ich den Prozessor heirate: Dann gibt es evtl. sogar absolut verlustfreie Losslessdateien, wenn ich eine MP3 erstelle! Wow, ich muss gleich mal die Öffnungszeiten vom regionalen Standesamt abklären...

Deine Unterschiede dürften daherkommen, dass Du zuviel rumprobierst. Erstelle doch Deine Files endlich mal nach den Vorgaben der EAC- und Foobar2000-Anleitungen bei AudioHQ. Hilft bestimmt... Wenn Du DANN noch immer dauernd unterschiedliche Files erhältst, wird's merkwürdig. Davon gehe ich nicht aus. Dass wäre dann aber schon einen separaten Thread wert.

Greez
Paesc

Danke für Deinen sachlichen Beitrag, hätte auch nichts anderes erwartet. Dieses Beispiel ist für jeden nachprüfbar, wer an der Wahrheit interessiert ist.
Oder man nimmt eben wieder seine Scheuklappen... (und träumt weiter von der heilen PC-Welt)

Das gleiche gilt für meine bis jetzt unbeantwortet gebliebene Frage:

Weiß jemand, wie die Signale im System-Mixer gemischt werden? Dies dürfte doch wohl digital sein und dann erst in der Summe zu Analog gewandelt werden. Das heißt, wenn ich über StereoMix aufnehme und alle überflüssigen Inputs ausschalte, dann sollte kein Analog(Stör)signal in die Aufnahme einstreuen können. Oder sehe ich das falsch?

Damit dürften bei vergangenen Tests (Grafikkarte auf Klang usw. ...) wo ich über StereoMix aufgezeichnet habe, eine Einwirkung von elektromagnetischen Störungen oder Einflüssen im nachhinein ausgeschlossen werden können.

deltaalpha66 schrieb:

Danke für Deinen sachlichen Beitrag, hätte auch nichts anderes erwartet. Dieses Beispiel ist für jeden nachprüfbar, wer an der Wahrheit interessiert ist. Oder man nimmt eben wieder seine Scheuklappen... (und träumt weiter von der heilen PC-Welt)

Aha. Dann war das wohl nicht sachlich genug:

Paesc schrieb:

Deine Unterschiede dürften daherkommen, dass Du zuviel rumprobierst. Erstelle doch Deine Files endlich mal nach den Vorgaben der EAC- und Foobar2000-Anleitungen bei AudioHQ. Hilft bestimmt... Wenn Du DANN noch immer dauernd unterschiedliche Files erhältst, wird's merkwürdig. Davon gehe ich nicht aus. Dass wäre dann aber schon einen separaten Thread wert.

Greez
Paesc

Es lohnt manchmal gründlich zu sein. Wie ich schon vermutet habe, es tritt also auch bei neueren Lame-Versionen auf.

Ist zwar zufällig noch 'ne Alpha-Vers. lame3.98a11 -V2 --vbr-new:
Comparing:
"D:\temp\Test\Test 1 - V2 VBR-New Athlon 2500+XP\17 - Pink Floyd - The Wall (1).mp3"
"D:\temp\Test\Test 1 - V2 VBR-New Pentium 3.0GHzXP\17 - Pink Floyd - The Wall (1).mp3"
differences found: 1493 sample(s), starting at 10.9468934 second(s), peak: 0.0000709 at 10.9636054 second(s), 1ch

Alle anderen Files aus Test1 = bit-identisch.

-----------------
Richtig krass wird es bei Lame 3.97Final -V2 --vbr-new:
Comparing:
"D:\temp\Test\Test 1 - V2-VBR-New Lame3.97 Athlon2500-XP\03 - Bellamy Brothers - Let Your Love Flow.mp3"
"D:\temp\Test\Test 1 - V2-VBR-New Lame3.97 Pentium 3GHzXP\03 - Bellamy Brothers - Let Your Love Flow.mp3"
differences found: 197468 sample(s), starting at 1.1722449 second(s), peak: 0.1448003 at 4.5437415 second(s), 2ch
Comparing:
"D:\temp\Test\Test 1 - V2-VBR-New Lame3.97 Athlon2500-XP\15 - Modern Talking - Your My Heart.mp3"
"D:\temp\Test\Test 1 - V2-VBR-New Lame3.97 Pentium 3GHzXP\15 - Modern Talking - Your My Heart.mp3"
differences found: 5531 sample(s), starting at 15.4656009 second(s), peak: 0.0508926 at 15.4839002 second(s), 1ch
Comparing:
"D:\temp\Test\Test 1 - V2-VBR-New Lame3.97 Athlon2500-XP\16 - Pink Floyd - In The Flesh.mp3"
"D:\temp\Test\Test 1 - V2-VBR-New Lame3.97 Pentium 3GHzXP\16 - Pink Floyd - In The Flesh.mp3"
differences found: 28364 sample(s), starting at 7.6816327 second(s), peak: 0.0410564 at 19.6932880 second(s), 1ch

Alle anderen Files aus Test1 = bit-identisch.

Habe ich evt. irgendwas verkehrt gemacht wie:

Paesc schrieb:

Files, welche um Mitternacht bei Vollmond erstellt werden, besonders toll sind. Ich hatte den Eindruck, ein leises Heulen eines Werwolfs und das Pfeifen eines Vampirs zu hören. Echt cool und gruselig! Ach ja, natürlich ist es auch unbedingt zu empfehlen, den PC mit Weihwasser zu übergiessen (der Prozessor muss natürlich auch übergossen werden). Das beseitigt böse Einstreuungen und Störungen, künftig werden sie sich auch nicht mehr so schnell einmisten. Nach 6 Monaten wiederholen. Zur Not kann man auch mit Knoblauch, Silber usw. den PC bearbeiten, so dass Vampire nicht an den Buchsen nuckeln können. Ach ja, den PC nach den Regeln von Feng Shui ausrichten. Hilft enorm. Wasseradern spielen auch eine grosse Rolle. Im Sommer wennmöglich keine Files erstellen, die mögen es lieber kühl und dunkel. Oh, noch was: vielleicht gibt es ja viel bessere Files, wenn man den Prozessor streichelt und knuddelt! Vielleicht war das bei Deinen Intel- oder AMD-Prozessoren so. Die brauchen auch Liebe. Geschweige denn, wenn ich den Prozessor heirate: Dann gibt es evtl. sogar absolut verlustfreie Losslessdateien, wenn ich eine MP3 erstelle! Wow, ich muss gleich mal die Öffnungszeiten vom regionalen Standesamt abklären...

Vielleicht fehlen mir aber einfach die Räucherstäbchen oder ich sollte meine Rechner nun doch umstylen...

Hi,

könnte es an den verschiedenen Befehlssätzen der AMD & Intel Prozessoren liegen? Dann müssten sich die Dateien unterscheiden, obwohl das Ergebnis am Ende trotzdem Looseless ist, da ja auch ein Intel-System diese Datei lesen, nur dass er dann vllt. eine 1000stel Millisekunde länger braucht, weil der Befehlssatz fehlt. Trotzdem wären die Datein Looseless.

Nunja... ein Versuch "die Heile PC-Welt zu retten", denn eine physikalische Erklärung alá Streueffekte durch Lorentzkraft ist mir ein wenig zu abwegig...

Viele Grüße

deltaalpha66 schrieb:

Vielleicht fehlen mir aber einfach die Räucherstäbchen oder ich sollte meine Rechner nun doch umstylen...

Mal eine ganz blöde Frage zum Ausgangsmaterial. Hast Du eine Wav-Datei, die Du zum Vergleich unterschiedlich wandelst, oder liest Du sie jedes mal neu von der CD?

Er macht einfach irgend etwas. Er hat selbst schon zugegeben, dass er nicht immer weiss, was er da genau tut, aber Unterschiede feststellen könne. Er fummelt mit irgendwelchen Einstellungen rum, stellt absurde Thesen in den Raum, zumeist ohne jegliche Grundlagen. Zudem hat er seine Matrix-Geschichte und andere merkwürdige Behauptungen schon in diversen anderen Foren breitgeschlagen - teils schon vor 3 Jahren! Damit verunsichert er höchstens noch andere Mitleser, die noch nicht sattelfest sind.

Auch antwortet er selbst nach mehrfacher Aufforderung nicht oder nur kurz angebunden auf Fragen anderer. Andere Meinungen und Tipps interessieren ihn nicht gross. Er will aber natürlich trotzdem Antworten auf diverse Fragen seinerseits und betont immer wieder, dass es keine "heile PC-Welt" gibt und man alles mögliche hinterfragen muss. Dass es keine "heile PC-Welt" gibt, wissen wir alle, hierfür brauchen wir keine Belehrungen von deltaalpha66 - und genauso wenig sinnfreie und an den Haaren herbeigezogene Behauptungen. Seine Tests mit Foobar2000 lassen zudem keine allgemein gültigen repräsentativen, 100%igen Aussagen zu, da hierfür die Trefferquote noch immer zu gering ist.

Er stellt somit die langjährige Arbeit diverser versierter Leute bei AudioHQ, HydrogenAudio und anderen Plattformen in Frage, weil er überzeugt ist, Anhaltspunkte gefunden zu haben, welche anderen angeblich bei ihrer Arbeit entgagen sein sollen. Begründung: Man habe eine Scheuklappe vor den Augen, lebe in einer heilen PC-Welt. Aber wie gesagt kann er seine Befunde nicht eindeutig und zweifellos nachweisen. Er lädt laufend Files hoch, anstatt andere miteinzubinden und so aktiv teilhaben zu lassen (was bei Verbesserungen von Audio-Codecs schon lange selbstverständlich ist). Zudem beweist er mit seinen Beiträgen, dass er mit dem Digitalbereich nicht allzu tief vertraut ist.

Sorry, aber das ist meiner Ansicht nach keine Art, in einem Forum zu kommunizieren... Forum-Jumper, welche dieselbe grundlagenfreie Geschichte x-fach und wiederholt in anderen Foren einbringen, sind ohnehin bei einigen Foren-Usern nicht besonders beliebt. Es ist kein Wunder, dass in diesem Thread nur noch sehr wenige aktiv teilnehmen. Ist vielleicht auch besser so, sonst hört das nie auf...

@Garfield360: Besten Dank für Deine Anmerkung. Ich hoffe, wir alle können es nun dabei belassen, sonst wird das hier eine "never ending story"...

Greez
Paesc

Piggel schrieb:

Mal eine ganz blöde Frage zum Ausgangsmaterial. Hast Du eine Wav-Datei, die Du zum Vergleich unterschiedlich wandelst, oder liest Du sie jedes mal neu von der CD?

Die 20 wavs (jeweils ca. 20sek) sind die gleichen (wie anfangs gehabt) und sind immer noch unter (Test1) runterzuladen:
http://www.megaupload.com/?d=U0J0AE5B

Paesc schrieb:

Er macht einfach irgend etwas

Habe mich mit -V2 --vbr-new nicht genau an die Empfehlung von Audiohq gehalten?
http://www.audiohq.de/index.php?showtopic=47

Wählen Sie unter Parameter passing scheme den Eintrag User defined encoder aus (nicht LAME MP3 Encoder!). Geben Sie unter Use file extension .mp3 ein. Klicken Sie auf Browse, wechseln Sie zum Ordner, in den Sie die lame.exe entpackt haben, und wählen Sie diese aus. Fügen Sie die folgende Zeile in Additional command line options ein: -V 2 --vbr-new --id3v2-only --pad-id3v2 --ignore-tag-errors --tt "%t" --ta "%a" --tl "%g" --ty "%y" --tn "%n" --tg "%m" %s %d

Die Tags habe ich mir mal geschenkt.

Paesc schrieb:

Seine Tests mit Foobar2000 lassen zudem keine allgemein gültigen repräsentativen, 100%igen Aussagen zu, da hierfür die Trefferquote noch immer zu gering ist.

Ich hoffe Du meinst nicht die Überprüfung der Dateien mit Foobar2000/bit-compare, willst Du das jetzt auch noch in Frage stellen?

Für alle die nicht wissen, wie bit-compare benutzt wird: (die runtergeladene bit-compare.dll im Verzeichnis: Programme\Foobar2000\components einfügen)
Frank_Bicking schrieb 09-01-2007 zu Paesc:
http://www.digital-i...ng-joint-stereo.html

Du kannst das in foobar2000 sehr leicht überprüfen lassen, indem du beide Dateien in eine Playlist lädst, sie markierst, und im Kontextmenü "Utils | Bit-compare tracks" aufrufst. Das Ergebnis sollte so aussehen: Code: Comparing: C:\test1.mp3 C:\test2.mp3 No differences in decoded data found.

Was daran hast Du nicht verstanden? Mal abgesehen davon war Frank_Bicking schon ein oder mehrere mal hier reinschauen, allerdings ohne Beitrag...
Ich hätte auch nichts dagegen, wenn er sich hier mal zu Wort meldet.

Ansonsten möchte ich noch mal darauf hinweisen, dass diese Unterschiede nicht bei allen 20 Testfiles auftraten, deshalb kommt wohl auch eine abweichende Kommandozeile auf verschiedenen Rechnern nicht in Frage.
Des weiteren dürfte man bei -V 2 --vbr-new nicht viel verkehrt machen können. Auch die jeweiligen Lame-Versionen waren identisch.

Paesc schrieb:

Aber wie gesagt kann er seine Befunde nicht eindeutig und zweifellos nachweisen. Er lädt laufend Files hoch, anstatt andere miteinzubinden und so aktiv teilhaben zu lassen

Was konkret habe ich verkehrt gemacht? Wie genau sollte ich denn meine Befunde noch darstellen?

Paesc schrieb:

hierfür brauchen wir keine Belehrungen von deltaalpha66

Ich hatte bisher eher den Eindruck dies sei andersrum, mir wurde "Lern-Resistenz" und "Sturheit" vorgeworfen

Paesc schrieb:

Der deltaalpha66 scheint nicht nur lernunwillig, sondern auch ausgesprochen stur zu sein.

aber vielleicht hat mich ja mein Eindruck getäuscht.
Wer ist eigentlich "WIR", wen vertrittst Du hier? Vielleicht sollte ich meine Beiträge zukünftig vorher bei jemanden genehmigen lassen?