Aufnahmen voller Artefakte

Status
Für weitere Antworten geschlossen.
D

divy

Benutzer
Liebe Leute,

es handelt sich hierbei nicht um ein ausgesprochenes Problem zum Thmea Studiotechnik. Aber in diesem Unterforum haben wir ähnliche Beispiele schon in der Vergangenheit diskutiert, daher hier noch mal. Sicher interessiert das den Achten Zwerg, der sich an solchen Tüfteleien erfreut.

Hier geht es um eine Aufnahme mit den Phonostar-Radiorecorder einer DLF-Langen Nacht. Es handelt sich um zwei Aufnahmen, die hintereinander entstanden. Die erste ist ok, die zweite ist voller Artefakte, das Audio scheint sich übereinanderzulegen und hin- und herzuspringen. Wer sich nur einen ersten Eindruck davon machen möchte, der findet hier eine kurze wave-Datei:

https://dl.dropboxusercontent.com/u/57394117/canetti1.wav

und hier die verhuntzte Originaldatei in voller Länge.

https://dl.dropboxusercontent.com/u/57394117/Lange Nacht(Deutschlandfunk)_07.mp3

Es ist überhaupt nicht tragisch, wenn sich die zweite Stunde der Elias-Canetti-Nacht nicht reparieren lässt. Allerdings ist mir Ähnliches auch schon mal mit Interviews passiert. Nachdem ich in der Vergangenheit hier schon lernen konnte, was man in solchen schlimmen Fällen machen kann, fände ich es interessant, ob in solchen Fällen das Material noch zu retten ist.
Falls nicht, vielleicht kann ja jemand sagen, wie so etwas passieren kann, damit ich evtl. Fehlerquellen abstellen kann.

Lieben Gruß und Dank an Alle!
 
Guten Tag!

Man kann hier nichts mehr retten......da fehlen bruchteile des Interviews. Diese sind einfach nicht mehr vorhanden! Ich weiss nicht, wie Sie aufnehmen, aber ich würde den Stream rippen, sei es mit dem Firefox Downloadhelper oder mit dem VLC - PLayer!
 
Wie gesagt, es handelt sich um eine Aufnahme mit dem phonostar-Player. Das ist die Vollversion des dradio-Recorder. Das hat den Vorteil, das sich Aufnahmen programmieren lassen, der Computer aus dem Ruhezustand automatisch hochgefahren und nach der Aufnahme auch runtergefahren wird.

Ich habe aber den Verdacht, dass das Problem nicht beim Aufnehmen entstteht. Die Datei wurde von Audition zur Nachbearbeitung geöffnet. Es sollten vorne und hinten Teile entfernt werden, die nichts mit der Langen Nacht zu tun haben, die Lautstärke ein wenig angehoben werden. Schon nach dem Öffnen stellte ich fest, dass die Datei irgendwie zerfetzt worden ist.

Ich vermute, dass Audition beim Öffnen irgendetwas kaputt macht, denn mir ist dies auch schon zwei mal mit Interviews passiert. Die Originale waren zum Glück noch auf dem Rekorder, und die waren nicht kaputt. Zumindest bei den Interviews gehen die Dateien also erst beim zweiten Zugriff kaputt. Viellleicht auch ein Festplattenproblem? Kommt die mit den Zugriffszeiten nicht zurecht? Auf dem Desktop laufen bislang noch zwei ATA-Platten.
 
divy schrieb:
Es sollten vorne und hinten Teile entfernt werden,
Zum Vergrößern anklicken....
Da möchte ich mal die Frage aufwerfen, warum Du für so eine einfache Aufgabe eine solch aufgeblasene und resourcenhungrige Software verwendest. Genau für solche Zwecke, also einfache Schnitte, Gainen und Faden an MP3s ist MP3DirectCut das zuverlässigste Mittel. Es ist nicht nur klein, fein und portabel, sondern hat entgegen fast aller Audioeditoren den Vorteil, seine Arbeit ohne De- und Recoding des Materials zu verrichten, was die Qualität dessen erhält.

Ist eine Datei erst einmal kaputt, kann das Programm freilich auch nichts mehr reparieren. Bei MP3 werden die Audiodaten in sogenannten Frames, also Blöcken gespeichert. Jeder dieser enthält einen Header mit genauen Anweisungen, wie ein Decoder mit den Daten zu verfahren hat. Anders als bei einem PCM-Stream, bei dem man gelegentliche Bitfehler zunächst erstmal gar nicht ohne weiteres hören muss, bedeutet auch nur ein falsches Bit in einem MP3-Stream schnell den Ausfall eines ganzen Frames, also den Verlust von Signal bis hinauf in den Millisekundenbereich.

Auf welche Weise solche Fehler auf deinem Rechner entstehen, kann man nur mutmaßen. Die Glaskugel legt Transferfehler nahe, aber die können an unzähligen Stellen entstehen: Unglückliches DMA-Handling, Speicherfehler, Timing- und Auslastungsprobleme - alles sehr tiefliegend und kaum offensichtlich. Auf keinen Fall so offensichtlich wie deine Vermutung, dass deine
divy schrieb:
zwei ATA-Platten
Zum Vergrößern anklicken....
das Problem wären. Ein gut und stabil laufender eIDE-Controller mit entsprechenden Festplatten ist bei weitem performant genug, ein bisschen MP3 zu transferieren. Ob er in Verbund mit anderer Hardware im Rechner tatsächlich richtig betrieben wird, ist eben eine andere Frage.

Was aber eigentlich gar nicht passieren dürfte, ist
divy schrieb:
dass Audition beim Öffnen irgendetwas kaputt macht
Zum Vergrößern anklicken....
Grundsätzlich sollte eine Software beim Öffnen einer Datei auch wirklich nichts anderes tun als "Open for read". Es gibt ja keinen Grund, das Lesen von Daten mit einem schreibenden Zugriff auf die entsprechende Datei zu begleiten. Es gibt allerdings Programme, wie beispielsweise den widerwärtigen Windows Mediaplayer, der tatsächlich eine MP3-Datei nicht einfach abspielt, sondern bei jedem Zugriff seinen Fußabdruck in selbige schmiert. Eigentlich sollte er dort nur Metadaten bearbeiten, aber das reicht schon aus, um sinnlose Unordnung auf dem Datenträger zu erzeugen.
Ob Audition ähnliches tut und sich dabei an mehr als nur den Metadaten von Dateien vergreift, kann ich nicht sagen. Ich traue Adobe aber durchaus einiges an Unsinn zu.
 
Hallo!

@divy: Ich würde auch zu mp3DirectCut raten. Und das Programm kannst dann auch gleich ausprobieren, indem du < 1 Minute aus der (ungeschnittenen Originalaufnahme) der funktionierenden mp3-Datei (erste Stunde) markierst und dann mittels "Markierung speichern" abspeicherst. Diese Datei hätte ich dann gern gesehen.

Das ist die Vollversion des dradio-Recorder. Das hat den Vorteil, das sich Aufnahmen programmieren lassen, der Computer aus dem Ruhezustand automatisch hochgefahren und nach der Aufnahme auch runtergefahren wird.
Zum Vergrößern anklicken....

Okay - das Ding zeichnet also den Webstream vom DLF auf. Hier stellt sich die Frage, woher die Bitrate von 256 kBit in der Datei herkommt. Laut http://www.deutschlandradio.de/radiohoeren-auf-deutschlandradio-de.219.de.html gibt es den mp3-Stream nur bis 128 kBit und der sollte dann auch 1:1 auf der Festplatte landen. Ein "Aufblasen" bringt ja nix.
 
Zuletzt bearbeitet:
@divy: Dieser Link wird dich brennend interessieren...
http://www.datenfeger.de/webradio-zeitgesteuert-aufnehmen/



Also ich tippe, daß der Stream während der Aufnahme der Sendung "geklemmt" hat. Der "phonostar" hat diesen fehlerhaften Stream dann transcodiert (und dabei auf 256 kBit aufgeblasen). Die so entstandene mp3-Datei ist soweit in Ordnung (die Framestruktur), nur das vom Webstream dekodierte "Quellmaterial" für die neue Datei (z.B. "LangeNacht(Deutschlandfunk)_07.mp3") "klang" halt schon so "zerfetzt". Auf gut Deutsch: Da gibt es nichts zu retten.



Das Folgende ist mehr was für dea:

Wir haben eine Datei mit 44.1kHz 256 kBit/s Stereo CBR.

Über

Framegröße = (144 × Bitrate) / Samplerate + Padding [bytes]

mit

Bitrate = 256000
Samplerate = 44100

komme ich bei einer Integerdivision auf 835 Bytes pro Frame.

Das stimmt auch, denn das erste Frame ist 835 Bytes lang. Normalerweise kann man das so lassen und die Datei Frame für Frame schreiben. Lustigerweise folgt dann aber eine Sequenz mit gepaddeten Frames (aufgerundet auf 836 Bytes). Bei MP3 wird ein Byte am Ende des Frames angefügt, damit der Frame eine gerade Länge bekommt. Nötig ist das nicht, denn pro Minute sind das rund 2300 Bytes mehr Dateigröße. Wenn ich padden würde, würde ich ja wenigstens eine Null nehmen (oder wie bei x86-Programmen einen INT3-Code). Das ist hier nicht der Fall, wie ein Blick in die Datei mit einem Hex-Editor zeigt. Entweder sind das zufällige Bytes oder "geheime Botschaften"... ;)

Hier die ersten Offsets aus der MP3-Datei...

0 0x00000000 Size 0 256kBit 44100Hz Ster I-St: off; M/S-St: off
1 0x00000343 Size 835 256kBit 44100Hz Ster I-St: off; M/S-St: off
2 0x00000687 Size 836 256kBit 44100Hz Ster I-St: off; M/S-St: off
3 0x000009CB Size 836 256kBit 44100Hz Ster I-St: off; M/S-St: off
4 0x00000D0F Size 836 256kBit 44100Hz Ster I-St: off; M/S-St: off
5 0x00001053 Size 836 256kBit 44100Hz Ster I-St: off; M/S-St: off
6 0x00001397 Size 836 256kBit 44100Hz Ster I-St: off; M/S-St: off
7 0x000016DB Size 836 256kBit 44100Hz Ster I-St: off; M/S-St: off
8 0x00001A1F Size 836 256kBit 44100Hz Ster I-St: off; M/S-St: off
9 0x00001D63 Size 836 256kBit 44100Hz Ster I-St: off; M/S-St: off
10 0x000020A7 Size 836 256kBit 44100Hz Ster I-St: off; M/S-St: off
11 0x000023EB Size 836 256kBit 44100Hz Ster I-St: off; M/S-St: off
12 0x0000272F Size 836 256kBit 44100Hz Ster I-St: off; M/S-St: off
13 0x00002A73 Size 836 256kBit 44100Hz Ster I-St: off; M/S-St: off
14 0x00002DB6 Size 835 256kBit 44100Hz Ster I-St: off; M/S-St: off

Viel Spaß! ;)
 
Nunja. Geheim ist das sicher nicht. Es ist ja nicht wie bei PCM, dass Du vom ersten Bit an die Audiodaten nachzählen könntest. Mit dem Bitratebalancing im Stereomodus, Short Frames / Long Frames und dem Bitreservoire hat man allein schon bei CBR standardmäßig einen unglaublichen Haufen Unwägbarkeiten. Mit ABR/VBR und JS wirds dann noch lustiger.
Wie dem auch sei: Im Normalfall funktioniert das alles ja glücklicherweise, ohne dass man sich mehr Gedanken um all den Kram machen müsste, als für die Arbeit mit dem Encoder und das Erstellen von Material nötig wäre.

Diesen Effekt, dass sich der Encoder so vollkommen verrechnet, kenne ich aber auch. Ich habe noch Audiomaterial hier, da wird noch viel mehr gewürfelt. Neben Bruchstücken unterschiedlicher Titel finden sich ein eiskaltes Rauschen, ein kurzes hohes Fiepen und jede andere Art von Störern und Krachen.
Schuld war Lame 3.99.3, der dann auch wegen eines Bugs (bei Gapless Encodung) schnell abgelöst wurde. Offensichtlich sind bei dieser Version im Speicher die tollsten Dinge passiert. Die Tatsache, dass in einem Titel Bruchstücke anderer auftauchen, deutet ja schon darauf hin, dass der Prozess seine Daten im RAM nicht da wiederfand, wo er sie mal hingeschmiert hatte und auch von der Festplatte las, was er gerade lustig war. Dumm nur: Ich wollte damals mit dem damals neuen und herverorragenden ABR-Algotythmus (Tod dem Bitreservoire!) das gesamte CD-Archiv rippen. Ein paar Tage Arbeit mit CDs Waven und nachts die Stapel rendern waren einigermaßen umsonst, weil immer wieder in irgendwelchen Titeln solcher Kram auftaucht.

Störsplatter habe ich übrigens auch auf einer inkontinenten SD-Karte. Die hält nicht länger als runde drei Monde ihre Daten. Dann geht langsam Bit für Bit verloren. Wenn dann endlich allzuviele Dateien allzusehr zerfetzt sind, wird einfach aus dem Archiv neu aufgezogen und dann geht das wieder eine Weile. Im MP3-Player geht das schon, zeigt aber eindrucksvoll, wie dramatisch sich das "digitale Vergessen" einer simplen 1 oder 0 bei MP3 auswirkt. Der Test mit Wave auf dieser Karte war dagegen eher undramatisch. Ehe sich Bitfehler da zu einem Störgeräusch aufschaukeln, dauert es logischerweise länger, da einfach mehr zerstört werden muss, was aber den Ablauf der Datei dennoch nicht stört.

In divys Fall ist es aber scheinbar wirklich so, dass der Recorder sinnloserweise recodiert statt zu rippen und dabei auch noch richtig Fehler macht. Wer weiß, welchen Encoder man dort verwendet und wie buggy man ihn füttert. Das Ding wäre für mich aber schon allein des Recodierens wegen ein NoGo.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben