mp3directcut Spektogramm verändert

[StiefelriemenBill]

Hallo zusammen,

es heißt ja immer, dass mp3directcut die Datei unverändert lässt. Jetzt ist mir aber aufgefallen, dass sich doch etwas sichtbar verändert, auch wenn die Qualität scheinbar nicht abnimmt. Hier mal zwei Bilder des Spektogramms einer mp3 Datei bevor und nachdem ich sie in mp3directcut gespeichert habe:

vorher: https://ibb.co/Px158HJ

nachher: https://ibb.co/v1f9T4z

Ich habe nichts geschnitten oder so, lediglich in mp3directcut geöffnet und direkt wieder gespeichert. Vorher ging das vorherige Lied in MusicBee (ohne gapless playback) auch lückenlos in dieses hier über. Nach dem Speichern in mp3dc, wie gesagt ohne irgendetwas zu schneiden, ist allerdings eine Unterbrechung zu hören. Weiter ist mir noch aufgefallen, dass durch das Speichern in mp3dc Informationen über den Codec verloren gehen. In mp3tag zumindest steht dann nur noch MPEG 1 Layer III da, während vorher noch (LAME3.100) dahinter stand.

Habe ich mp3dircetcut irgendwie falsch konfiguriert oder lassen sich diese Veränderungen nicht verhindern?

LG

[mpesch3]

Die Spektren sehen doch gleich aus. Auch an der markierten Stelle.
mp3DC KANN die Qualität beim normalen Speichern gar nicht verändern.
Einzige Ausnahme ist natürlich, wenn man das neu eingebaute "Save re-encoded" nutzt.

Ja, es kann sein, dass Gapless-Informationen verloren gehen, wenn man den Lame-Tag nicht behält. Dazu muss im Info-Dialog "VBR/Info Header" und "Encoder Daten" angekreuzt sein. Sollte aber standardmäßig so sein.

[StiefelriemenBill]

Hallo,

also eigentlich sehen die nicht gleich aus. In dem markierten Bereich kann man eindeutig erkennen, dass bei Bild 2 (nach dem Speichern in mp3dc) deutlich mehr "Striche" über der 20 kHz Grenze liegen. Und allgemein sieht man gut, wie sich das ganze Spektrum etwas verändert, wenn man zwischen den Bildern hin und her tabt. Und das liegt nicht an dem Screenshot, ist, wenn ich die beiden Dateien in spek öffne und auf Vollbild hin und her tabe auch so. Also es scheint wie gesagt nicht wirklich was an Bitrate verloren zugehen, aber das Spektrum ist eben auch nicht das selbe. Sieht irgendwie aus, als seien die Bits anders verteilt.

Im Infodialog ist beides angekreuzt, leider besteht das Gapless Problem trotzdem.

[mpesch3]

Ja, man sieht auch, wie die Flugzeuge Chemtrails absondern, dass nie einer auf dem Mond war, dass wir von Echsenmenschen regiert werden und dass die Erde eine Scheibe ist.

Glaub, was du willst. Erklärt habe ich es dir.

[StiefelriemenBill]

Lässiger Typ... Weiß nicht, was das mit Glauben zutun hat und erklärt haste mir eigentlich nichts... Du scheinst genau so wenig wie ich zu verstehen, warum sich das Spektrum trotz Qualitätserhalt sichtbar verändert und tust einfach so, als würde man keinen Unterschied sehen.

Das mit der Codec Information haste komplett ignoriert und das mit den (standardmäßig ohnehin gesetzten) fehlenden Kreuzchen im Info-Dialog war auch nicht die Ursache für das gapless-Problem, welches immernoch besteht.

[mpesch3]

Nagut, nochmal ausführlicher:

- mp3DC kopiert die MP3-Daten. Es kopiert sie. So wie sie sind. Nur an den vom User definierten Schnitten natürlich nicht. Die Schnitte werden an den Grenzen von MP3-Frames gesetzt. Wegen Bit-Reservoir können die Schnitte unsauber werden. Aber nicht die MP3-Daten selbst. Denn die werden byte-genau kopiert. Nur dadurch kann mp3DC überhaupt so schnell speichern.

- Deine Spektren-Bilder lassen darauf schließen, dass du keine Dateien direkt analysiert hast, sondern analog eingespielt hast. Das würde die minimalen optischen Unterschiede erklären.

- Wenn sie doch direkt eingelesen wurden, ist vielleicht die Umrechnung auf die Fenstergröße minimal unterschiedlich.

- Bei einer Neukodierung sähe es deutlich anders aus - je nach Bitrate.

- Um sicher zu gehen, dass die Datei original geblieben ist, kannst du ja ein Vergleichstool einsetzen. Am Anfang (Header) und Ende (unvollständiger Frame, ID3 Tag) kann es aber auch bei ungeschnittenen Tracks Unterschiede geben.

- Die Gapless-Schnitte funktionieren glaube ich nur, wenn bereits ein Xing-/Info-Header mit Lame-Encoderdaten vorhanden ist. Sonst kennt mp3DC das "Encoder-Delay" nicht, das der Player nutzt, um die Lücke zu schließen.