AW: Cuepoint Charlie...
Hi, nochmal!
pmd6fix_001_beta.zip (8,5 KB, 1x aufgerufen)
Zumindest hat sich ein einziger User gefunden, der jetzt gerade seinen Rechner neu "aufsetzt" und daher im Moment nicht ins Internet kommt....
SCNR.
(Ich gebe zu, daß ich auch keinem Programm aus dem Internet ohne "Reputation" des Erstellers vertraue und es "blind" ausführe. Bei "soooooooooo" einem winzigen Programm schon gar nicht! Dabei ist das Progi so klein und überschaubar, daß ein Kenner der Materie keine Probleme haben dürfte alle Funktionen zu untersuchen... Egal.)
Ich weiß, die "Feierabendzeit" fängt erst an, wir warten also gemeinsam und gespannt auf die ersten Rückmeldungen am Abend.
Bis dahin will ich euch aber wenigstens auf ein möglicherweise neues Problem mit Marantz-Recordern hinweisen. (Ich habs gut, denn ich lese Wavedateien nach gut zwei Monaten Beschäftigung mit diesem Thema im Hexeditor fast so gut, wie ihr die Zeitung am Frühstückstisch. Das ist nunmal so und meiner "C-64-Vergangenheit" geschuldet. Assembler, C, "PEEK & POKE-BASIC-Orgien" und Hex-Editoren sind für mich keine Hacker-Tools/Tricks, sondern "vollig normal"...
Nun zum Problem:
In einer 24Bit/Mono-Datei eines PMD661 ist mir etwas aufgefallen, was sich
durchaus auch wieder ein weiterer Fehler von Marantz herausstellen könnte.
Folgendes:
Normalerweise lohnt es sich wirklich nicht mit 24 Bit über die (internen) Mics aufzunehmen. Einziger Vorteil: Man kann (theoretisch) mit einem Spitzenpegel von -48dBFS arbeiten, ohne bei der späteren Normalisierung der Aufnahme im Soundeditor unter die 16 Bit-(Qualitäts)Schwelle zu rutschen. Das ist aber nur Theorie...
24 Bit "passen" natürlich in drei Bytes und darum wird ein "Mono-Sample" auch in drei Bytes abgespeichert. Man könnte die Samples auch "padden" und noch ein Nullbyte schreiben. Der Verbrauch an Speicherplatz ist dann selbstverständlich 25% größer, was natürlich nicht im Sinne des Erfinders ist. Dafür hat die Datei dann aber auch immer und garantiert eine gerade Größe.
Die Frage ist nun, ob Marantz "aufgepasst hat" und dafür sorgt, daß die geschriebenen Audiodaten im data-Chunk (ohne gesetzte Marken!) immer eine gerade Länge haben, also notfalls noch ein "Padd-Byte" schreibt. Anderenfalls besteht nämlich eine 50%ige Chance, daß die Datei am Ende eine ungerade Länge hat und WaveLab beim Öffnen, wie hier im Thread von cj zufällig festgestellt, "rumzickt".
So wie ich den "ungeraden" ID32-Chunk aus der "Hallo Herr Siegert"-Datei kenne, liegt das also durchaus im Bereich des Möglichen.
Ich werde in Kürze ein kleines Tool liefern, welches dieses Problem "erkennt" und notfalls behebt. Ebenso wird es wohl ein Tool geben, welches als "Krücke" für WaveLab dient und die standardmäßigen Marker in den Wavedateien eines "Zoom" (o. a. Recorder?) so "frisiert", damit WaveLab die Marker auch erkennt. Alle Hintergründe stehen hier im Thread.
Grüßle Zwerg#8
