AVAudioRecorder schreibt keinen richtigen WAV File Header

Apple-Software erstellt häufig WAVE-Dateien mit einem nicht standardmäßigen (aber "spezifikationskonformen") "FLLR" -Unterverzeichnis nach dem Unterverzeichnis "fmt " und vor dem Unterverzeichnis "data" . Ich nehme an, "FLLR" steht für "fillers", und ich nehme an, dass der Zweck des Subchunks darin besteht, eine Art Datenausrichtungsoptimierung zu ermöglichen. Das Subchunk ist normalerweise ungefähr 4000 Bytes lang, aber seine tatsächliche Länge kann abhängig von der Länge der Daten variieren, die ihm vorausgehen.

Das Hinzufügen beliebiger Subchunks zu WAVE-Dateien wird im Allgemeinen als spezifikationskonform betrachtet, da WAVE eine Untergruppe von RIFF ist, und das allgemeine Praxis in der RIFF-Dateiverarbeitung besteht darin, Chunks und Subchunks zu ignorieren, die einen nicht erkannten Bezeichner haben. Der Bezeichner "FLLR" ist "nicht-standard" und sollte daher von jeder Software ignoriert werden, die darauf trifft.

Es gibt eine ganze Menge Software, die das WAVE-Format viel strenger behandelt, als es sollte, und ich vermute, dass die von Ihnen verwendete Bibliothek eine dieser Software-Komponenten ist. Zum Beispiel habe ich Software gesehen, die annimmt, dass die Audio-Bytes immer bei Offset 44 beginnen - dies ist eine falsche Annahme.

Tatsächlich müssen die Audiobytes in einer WAVE-Datei gefunden werden, indem der Ort und die Größe des "data" Subchunks innerhalb des RIFF gefunden werden; Dies ist der richtige Weg, um die Audio-Bytes in einer WAVE-Datei zu finden.

Das korrekte Lesen von WAVE-Dateien muss wirklich als Übung zum Auffinden und Identifizieren von RIFF-Subchunks beginnen. RIFF-Subchunks haben einen 8-Byte-Header: 4 Bytes für ein Identifier / Name-Feld, das traditionell mit für Menschen lesbaren ASCII-Zeichen (zB "fmt " ) gefüllt ist, und eine 4-Byte-Little-Endian-Ganzzahl ohne Vorzeichen, die die Anzahl der Bytes angibt Die Datennutzlast des Subchunks - die Datennutzlast des Subchunks folgt unmittelbar nach seinem 8-Byte-Header.

Das WAVE-Dateiformat reserviert bestimmte Subchunk-Identifikatoren (oder "Namen") als für das WAVE-Format bedeutsam. Es gibt mindestens zwei Subchunks, die immer in jeder WAVE-Datei erscheinen müssen:

1. "fmt " - Das Subchunk mit dieser Kennung hat eine Payload, die die grundlegenden Informationen über das Audioformat beschreibt: Abtastrate, Bittiefe usw.
2. "data" - Das Subchunk mit dieser Kennung hat die eigentlichen Audio-Bytes in seiner Nutzlast

"fact" ist die zweithäufigste Subchunk-ID. Es wird normalerweise in WAVE-Dateien gefunden, die einen komprimierten Codec verwenden, wie zB μ-law. Auf dieser enthusiastischen Webseite finden Sie weitere Informationen zu einigen die verschiedenen Subchunk-Identifikatoren, die heute in freier Wildbahn verwendet werden, und Informationen über ihre Nutzlaststruktur.

Aus rein RIFF-Perspektive müssen Subchunks nicht in einer bestimmten Reihenfolge in der Datei oder in einem bestimmten festen Offset angezeigt werden. In der Praxis erwartet jedoch fast die gesamte Software, dass das Unterverzeichnis "fmt " das erste Subchunk ist. Dies ist ein Zugeständnis an die Praxistauglichkeit: Es ist praktisch, früh im Datenstrom zu wissen, welches Audioformat der WAVE enthält - das macht es beispielsweise einfacher, eine Wave-Datei aus einem Netzwerkstream abzuspielen. Wenn die WAVE-Datei ein komprimiertes Format verwendet, wie z. B. μ-law, wird normalerweise angenommen, dass das Unterverzeichnis "fact" direkt nach "fmt " erscheint.

Nachdem die formatspezifizierenden Chunks aus dem Weg geräumt sind, sollten Annahmen über den Ort, die Reihenfolge und die Benennung von Subchunks aufgegeben werden. Zu diesem Zeitpunkt sollte die Software erwartete Subchunks nur nach ihrem Namen lokalisieren (z. B. "data" ). Wenn Subchunks gefunden werden, die unerkannte Namen haben (z. B. "FLLR" ), sollten diese Subchunks einfach übersprungen und ignoriert werden. Das Überspringen eines Subchunks erfordert das Lesen seiner Länge, damit Sie die korrekte Anzahl von Bytes überspringen können.

Was Apple mit dem "FLLR" Subchunk gemacht hat, ist etwas ungewöhnlich, und ich bin nicht überrascht, dass einige Software davon stolpert. Ich vermute, dass die Bibliothek, die Sie verwenden, einfach nicht darauf vorbereitet ist, mit dem Vorhandensein des "FLLR" Subchunks umzugehen. Ich würde dies als einen Fehler in der Bibliothek betrachten. Der Fehler, den die Bibliotheksautoren gemacht haben, ist wahrscheinlich so etwas wie:

1. Sie erwarten möglicherweise, dass das Unterverzeichnis "data" innerhalb der ersten N Bytes des Dateianfangs erscheint, wobei N etwas kleiner als ~ 4kB ist. Sie können aufhören zu suchen, wenn sie zu weit in die Datei scannen müssen. Das Apple "FLLR" Subchunk schiebt das "data" Subchunk auf eine Position & gt; ~ 4kB in die Datei.

2. Sie erwarten möglicherweise, dass das Unterverzeichnis "data" eine bestimmte ordinale Subchunkposition oder einen Byteoffset innerhalb des RIFF aufweist. Vielleicht erwarten sie "data" unmittelbar nach "fmt " . Dies ist eine falsche Methode zum Verarbeiten einer RIFF-Datei. Die Ordinalposition und / oder Offset-Position des "data" Subchunks sollte nicht angenommen werden.

Solange wir über die korrekte Verarbeitung von WAVE-Dateien sprechen, kann ich auch alle daran erinnern, dass die Audio-Bytes (die Payload des data subchunk) möglicherweise nicht genau bis zum Ende der Datei laufen. Es ist zulässig, Subchunks nach % code% Nutzlast einzufügen. Einige Programme verwenden dies, um ein textuelles "Kommentar" -Feld am Ende der Datei zu speichern. Wenn Sie blind vom Beginn der data Nutzlast bis zum EOF lesen, können Sie einige Metadaten-Subchunks als Audio einlesen, was am Ende der Wiedergabe wie ein "Klick" klingt. Sie müssen das Längenfeld des Unterverzeichnisses data beachten und aufhören, Audio zu lesen, sobald Sie die gesamte Datennutzlast verbraucht haben - nicht aufhören, wenn Sie EOF drücken.

Wie lautet der Name der Datei, auf der Sie auf Festplatte aufnehmen? Ich hatte ein ähnliches Problem und habe es gelöst, indem ich .wav an das Ende meines Dateinamens angeheftet habe ... Ich denke, AVAudioRecorder benötigt eine Erweiterung, um die Dinge herauszufinden.