AC3 Dateien mit falscher byte order reparieren

SixdeeBee

Byte-Reihenfolge einer AC3 Datei mit dem Tool > AC3SWAP.EXE < korrigieren.

1. Einleitung

Ab und zu findet man in den Foren Themen wie dieses: TMPGEnc verweigert die Annahme einer AC3 Datei mit der Fehlermeldung > Illegal MPEG audiostream < .
Fast immer handelt es sich dabei um AC3 Dateien, die mit kommerziellen, zertifizierten Encodern erstellt wurden.
Dieses Verhalten wird noch ominöser, wenn die gleiche AC3 Datei auf einem Player mit DirectShow-AC3-Decoder problemlos abspielbar ist.
Die Ursache liegt in der falschen byte Reihenfolge (byte order) der AC3 Datei.

2.0 AC3 Spezifikation

Der AC3 Datenstrom ist in Pakete, die sogenannten frames, aufgeteilt. Jedes dieser Pakete
besteht aus einem header und den eigentlichen Audio-Daten und dauert 32ms. Im header sind alle Informationen untergebracht, die ein AC3 Decoder benötigt, um

* eine Datei als AC3 Datenstrom zu identifizieren
* die Audiodaten zu synchronisieren
* eine Fehlererkennung durchzuführen
* die Anwendervorgaben zu erkennen (Kanalzahl, Sample Rate usw.)

AC3 ist ein 16 bit Datenstrom, deshalb werden jeweils 2 byte zu einem Datenwort (word) zusammengefaßt.

Das erste word eines frames ist grundsätzlich immer das syncword 0B 77h. Daran erkennen sowohl Decoder als auch Muxer (z.B. TMPGEnc), daß es sich um eine AC3 Datei handelt.
Danach folgen 2 byte für den Fehlertest cyclic redundancy check 1 , gefolgt vom
sample rate code, der wiederum zusammengelegt ist mit dem frame size code usw.

Ein 2-Kanal AC3 Datenstrom mit 48kHz/192 kbps beginnt mit folgender Bitkombination:
(0B 77 xx yy 14 40)h, xx yy stehen für den CRC1 Test, sie variieren.

2.1 Byte order des Datenstroms

Es gibt zwei Möglichkeiten, ein 2-byte word zusammenzusetzen:

1. Das höherwertige byte erscheint zuerst, dann das niederwertige. (little endian)
2. Das niederwertige byte erscheint zuerst, dann das höherwertige. (big endian)

Angewandt auf den AC3 Datenstrom von 2.0 ergeben sich daraus folgende Möglichkeiten:

1. Gemäß ATSC Standard, Revision A von 2001: 0B 77 xx yy 14 40...
2. Gemäß Hausnorm des Encoder Vertreibers: 77 0B yy xx 40 14...:mad:

2.2 Wie erkenne ich den Datenstromtyp ?

Unter der Voraussetzung, daß ein DirectShow-AC3 Decoder auf dem PC installiert ist, kann mittels Graphedit und AC3Filter eine Aussage gemacht werden, um welchen Typ es sich handelt. Dazu die AC3 Datei starten und AC3 Filter öffnen. Erscheint unter > Decoder info < in der 5. Zeile > stream: 16bit big endian <, dann sind high- und low bytes vertauscht.

2.3 Verändern der byte order mit dem Tool > AC3SWAP.EXE vers 1.0 <

Der Vorgang des Vertauschens einer bestehenden byte order heißt swapping und genau dies
macht das kleine Kommandozeilenprogramm AC3SWAP.

Am einfachsten funktioniert dies, wenn AC3SWAP und die AC3 Datei im gleichen Verzeichnis stehen.

Die Kommando-Eingaben > ac3swap SourceFile.ac3 < und > RETURN < starten den
swap Vorgang, wobei > SourceFile.ac3 < ein beliebiger Dateinamen sein darf.
Das Programm macht nun folgendes:

Einlesen: word 1 mit byte order H/L => speichern von word 1 mit byte order L/H
Einlesen: word 2 mit byte order H/L => speichern von word 2 mit byte order L/H usw.

Die ursprüngliche Quelldatei wird dabei nicht verändert, es erscheint eine neue Datei
> s_SourceFile.ac3 <, in der die byte order nun richtig ist; AC3 Filter zeigt > stream: 8bit <

Einschränkungen:

Die AC3 Datei sollte vom Typ > Even < sein, d.h. die Gesamtanzahl der bytes muß durch
2 ohne Rest teilbar sein. Ist sie das nicht, dann ist entweder ein byte "abhanden" gekommen oder es wurde ein vagabundierendes byte (von wo auch immer...) eingefangen (Die Vogelgrippe grassiert zur Zeit im Lande ...). Passiert dieser Fehler am Ende der Datei, dann ist das nicht weiter schlimm, und es könnte u.U. nur ein "Klick" im letzten audio frame entstehen. Beginnt die Datei nicht mit einem vollständigen synchword, dann wird u.U. die Zieldatei unbrauchbar sein!
Ist SourceFile.AC3 eine Datei vom Typ > Odd <, erscheint die Meldung:

Odd file size, target could be unusable, use an hexeditor!

Fehlt nur das erste byte, so kann man mittels eines Hexeditors und der > Insert string < Funktion die Datei ergänzen. Fehlt mehr, dann hilft nur noch das Entfernen des ersten frame Fragments bis vor das synchword des nächsten frames. Diese Änderungen müssen an der Quelldatei vorgenommen werden, bevor AC3SWAP die bytes vertauscht.

AC3SWAP ist Freeware und darf ohne Einschränkungen genutzt werden. Das Programm
wurde in C++ geschrieben und compiliert mit dem Freeware C++ Compiler Dev-C++ 4.9.9.2.

Viel Erfolg beim Swappen ...;D

LigH

:daumen: Vielen Dank.

AC3-Streams in "falscher" Reihenfolge dürften hoffentlich nicht oft vorkommen; wenn doch, wäre mal interessant, ob es prominente Beispiele gibt. DVD-Video jedenfalls verwendet normalerweise Motorola-Format (little endian - menschenlesbare Reihenfolge) anstatt intel-Format (big endian, Wertigkeits-Reihenfolge).

Der AC3Enc in BeSweet ist auch in der Lage, sowohl intel- als auch Motorola-Reihenfolge zu erzeugen. Muss also nicht unbedingt teure Software gewesen sein.

SixdeeBee

Ja, es gibt zumindest ein Beispiel: Die französische Firma Digigram hat bis 2002 einen von Dolby zertifizierten AC3 Encoder angeboten, der ausschließlich die "falsche" Reihenfolge verwendet hat. In der kommerziellen
Rundfunk-Technik scheint dies öfter üblich zu sein um MacIntosh Systeme
bedienen zu können (68000xx CPUs). Leider hat Digigram diesen Encoder
dann auch unverändert für Windows-Systeme angeboten ...:D

Dieser Encoder scheint häufiger in den USA verwendet worden zu sein, zumindest stammen die meisten Klagen über dessen "falsche" AC3 Dateien aus Übersee.

.. na ja und ich bin auch darauf reingefallen, deshalb das kleine "Reparatur"
Tool ... und möglicherweise hat ja der eine oder andere den Encoder noch
in der Schublade liegen und konnte bisher nichts damit anfangen ... nun gehts .
Das Tool funktioniert auch rückwärts, man kann damit BeSweet-AC3 nach
> MacIntosh < -AC3 umwandeln.

Zumindest ist die Qualität der Digigram-AC3-streams sehr gut, der Störabstand eines 1kHz Sinus in 48kHz/448kbps streams beträgt auf allen 5 Kanälen >96dB (der Referenz-Sinus hatte > 130dB), nur im Lfe Kanal, da hat die einfache ac3enc.dll von Head-AC3 zumindest gleich gut abgeschnitten ...

SixdeeBee

LigH

Für DVD-Player wäre die Motorola-Reihenfolge eigentlich "richtig", oder zumindest typisch, denn auch LPCM wird in dieser Reihenfolge verwendet.

Die Begriffe "richtig" oder "falsch" sind eigentlich grundsätzlich unangebracht. Dass ein Authoringtool eine der beiden verweigert, kann zwei Ursachen haben: a) Das Authoringtool weiß, dass es auf DVD verboten ist / b) Das Authoringtool weiß nicht, dass es auf DVD erlaubt ist. Um zu wissen, ob a) oder b) hier der Fall ist, müsste ich allerdings erst mal genau wissen, ob intel-AC3 auf Video-DVD erlaubt ist...

SixdeeBee

... Hmm... "true" = wahr und "false" = "falsch" sind Begriffe, die den "Nagel" auf den Kopf treffen ... Funktioniert es nicht ist halt was "falsch". Es sind ja nicht nur Authoring-Programme, die nicht damit funktionieren, sondern auch AC-3 fähige Schnittprogramme wie z.B. Wombles MPEG-Wizard. Zum Encoder gehört auch ein Decoder, der grundsätzlich nur das eigene Format decodiert und das "Win-übliche" als "falsch" bezeichnet ... und zwar wörtlich !:mad:

Gemäß dem ATSC Standard Revision A (2001) ist die Reihenfolge vorgegeben: Dort steht auf Seite 33: "The syncword is always 0x0B77h...". Fragt nun ein Decoder oder Muxer diese Bytes in genau dieser Reihenfolge ab, dann werden sie als "true" erkannt. Steht dort 770Bh dann ist das "false" womit wir wieder bei "falsch" wären ... oder bei > Illegal <, wie es der TEMPGEnc Muxer deklariert.:D
Der Standard sagt nämlich noch mehr " ... Transmission of the syncword, like
other bit field elements, is left bit first."
Damit ist die Leserichtung zwingend vorgeschrieben.
Geht man von > fifo < aus, dann liest ein Decoder ebenfalls > left bit first <.
Der umgekehrte Weg ist halt nur möglich, wenn das PC-System von Hause aus die Byte-lese-Richtung umgekehrt handhabt.:cool:
Da dieser Encoder ausdrücklich für Windows-Betriebssysteme bestimmt war,
ist die verwendete Byte Reihenfolge schlichtweg "falsch" oder sie war nur für
ein ganz bestimmtes Programm vorgesehen.. das konnte mir die Firma aber,
auf Anfrage, nicht nennen ...:motz:

Man kanns halt drehen und wenden, es klappt nur in einer Richtung und das ist dann die "richtige" ...:)

bergh

tach auch !

Das ist wie mit der field-order:
TFF, BFF
Richtig ist was der Standard erlaubt.
Bei DV ist BFF zwingend vorgeschrieben, was Generationen von Anfängern in den Wahnsinn getrieben hat. Falsch ist das nicht.

Aber egal
Schönen Dank für Deine Mühen.
UNd wenn ich weider mal einen
Grossen Indianer habe, dann kommt er ran,
der Clerasil ähhhh der SixdeeBee AC3Swapper !

SixdeeBee

... keine Ursache ...

Es wäre ja interessant, ob jemand ein Programm findet, das die
"verqueren" AC-3 Dateien akzeptiert .
Gibt man dem Tool eine Standarddatei vor, dann wird die "falsifiziert" (um das Reizwort "falsch" mal zu verklausulieren ...:D ).
Ich habe über ein Jahr vergeblich danach gesucht und als mir der
Kragen geplatzt ist, entstand das Tool ...
Jetzt ist der Kragenknopf zwar weg aber dafür funktionieren die AC-3 files ...:daumen:

bergh

tach auch !

Bei Adobe Audition kann man das doch auswählen, oder ?
(Oder es war nur beim Speichern auszuwählen ob man den Grossen , oder den Kleinen INdianer haben wollte)
Ich kann HIER jetzt gerade nicht nachschauen.
Mal sehen, ob zu Hause noch was vom Testzeitraum übrig ist.

DarkAvenger

Netter Artikel, aber einige Fehler:

- ac3 frame ist 1536 samples/Kanal lang, nicht 32ms. Ist zufällig bei 48kHz richtig.

- Erklärung little endian und big endian ist falsch (auch LigH hat es falsch herum), siehe auch hier: http://www.cs.umass.edu/~verts/cs32/endian.html

DarkAvenger

Aus Spaß an der Freud hier mal eine kurze C-Implementierung, die ich unter GPL stelle. So können auch Nicht-Windows-Nutzer damit etwas anfangen.

Es juckt mich ja etwas in den Fingern, MMX code einzubauen.

ACHTUNG: Den code nicht direkt copy und pasten, sondern auf zitieren gehen und dann dort copy & paste machen. Die Forumssoftware hatt offensichtlich eine Macke und beachtet den code tag nur unvollständig.

[edit]: Mit dem php tag Trick müßte das direkte copy & pasten funktionieren; (C) Jahr angepaßt...

byteswap.c

PHP

/***************************************************************************
 *   Copyright (C) 2006 by Dark Avenger                                    *
 *   darkav at gmx dot net                                                 *
 *                                                                         *
 *   This program is free software; you can redistribute it and/or modify  *
 *   it under the terms of the GNU General Public License as published by  *
 *   the Free Software Foundation; version 2 of the License                *
 *                                                                         *
 *   This program is distributed in the hope that it will be useful,       *
 *   but WITHOUT ANY WARRANTY; without even the implied warranty of        *
 *   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the         *
 *   GNU General Public License for more details.                          *
 ***************************************************************************/


#include <stdio.h>
#include <stdlib.h>


/* chunksize must be even ! */
#define chunksize (1*1024*1024)


int get_filesize(FILE* file)
{
	int size;

	fseek(file, 0, SEEK_END);
	size = ftell(file);
	fseek(file, 0, SEEK_SET);

	return size;
}


int main(int argc, char *argv[])
{
	FILE *fin, *fout;
	int size;
	unsigned char *buffer;

	if (argc != 3) {
		printf("%s input output\n", argv[0]);
		return 1;
	}

	fin = fopen(argv[1],"rb");
	if (!fin) {
		printf("could not open input\n");
		return 2;
	}

	size = get_filesize(fin);

	if (size & 1) {
		printf("filesize should be even\n");
		return 3;
	}

	fout = fopen(argv[2],"rb");
	if (fout) {
		printf("output already exists\n");
		fclose(fout);
		return 4;
	}

	fout = fopen(argv[2],"wb");
	if (!fout) {
		printf("could not open output\n");
		return 5;
	}

	buffer = malloc(chunksize);
	if (!buffer) {
		printf("could not allocate memory\n");
		return 6;
	}

	while (size) {
		int to_read = size >= chunksize ? chunksize : size;
		int i;

		fread(buffer, to_read, 1, fin);

		for (i = 0; i < to_read; i += 2) {
			unsigned char *b0 = buffer + i;
			unsigned char *b1 = buffer + i + 1;

			*b0 ^= *b1;
			*b1 ^= *b0;
			*b0 ^= *b1;
		}

		fwrite(buffer, to_read, 1, fout);

		size -= to_read;
	}


	free(buffer);
	fclose(fout);
	fclose(fin);


	return EXIT_SUCCESS;
}

Alles anzeigen

Kopernikus

Da fehlen includes! Das eine sollte stdio.h sein, das andere stdlib.h.

DarkAvenger

Zitat von Kopernikus

Da fehlen includes! Das eine sollte stdio.h sein, das andere stdlib.h.

Nein, tuen die nicht:

Zitat

ACHTUNG: Den code nicht direkt copy und pasten, sondern auf zitieren gehen und dann dort copy & paste machen. Die Forumssoftware hatt offensichtlich eine Macke und beachtet den code tag nur unvollständig.

LigH

^ Der PHP-Tag ist da zuverlässiger. Und durch Einfärbung der Strukturelemente auch noch evtl. besser lesbar.

DarkAvenger

Ah danke, interessanter Trick!

feelfree

Zitat von DarkAvenger
Code
*b0 ^= *b1;
*b1 ^= *b0;
*b0 ^= *b1;

Bytes vertauschen ohne Hilfsvariable...Faszinierend. Hab's gerade mit Bleistift und Papier nachgerechnet, weil ich es nicht glauben konnte

Als Autor von HeadAc3He hast Du bestimmt auch eine Idee zu diesem Thema, oder? http://forum.gleitz.info/showthread.php?t=26626

DarkAvenger

Ja, aber ich habe mir den assembler output mal angesehen. Schneller ist es wohl doch mit Hilfvariable, da wir mit 8bit und nicht 32 bit arbeiten. Naja... macht aber keinen Unterschied da die Festplatte die Bremse ist. Habe auch eine MMX Routine und davon abgeleitet mit 32 bit int was geschrieben, nur macht keinen Sinn wegen I/O... Aber bei Interesse kann man ja dieses Code Fragment begutachten:

PHP

unsigned int im2 = 0x00FF00FF;	unsigned int im1 = 0xFF00FF00;		for (i = 4; i < to_read; i += 4) {			unsigned int bin = *buffer;			unsigned int b1 = bin << 8;			unsigned int b2 = bin >> 8;			b1 &= im1;			b2 &= im2;			*buffer = b1 | b2;			buffer += 4;		}

Mit etwas Geschick könnte man obiges auch auf 64 bit longs auf Athlon64 selbst-tunend machend, also daß der bei 32bit 2 Werte und bei 64bit 4 Werte "swapt". Damit wäre es auf 64bit Plattformen so gut wie MMX.

und dasselbe in MMX (bringt aber nix; scheint sogar langsamer, habe aber das malloc auch nicht auf 8byte aligned):

PHP

#if __GNUC__ < 4
typedef short v4hi __attribute__ ((__mode__(__V4HI__)));
typedef int   v2si __attribute__ ((__mode__(__V2SI__)));
typedef int   di   __attribute__ ((__mode__(__DI__)));
#else
typedef short v4hi __attribute__ ((vector_size (8)));
typedef int   v2si __attribute__ ((vector_size (8)));
typedef int   di   __attribute__ ((vector_size (8)));
#endif


#define ALIGN16(x) x __attribute__((aligned(16)))


	union {
		unsigned short s[4];
		v4hi v;
	} ALIGN16(m2) = {{0x00FF, 0x00FF, 0x00FF, 0x00FF}};

	union {
		unsigned short s[4];
		v4hi v;
	} ALIGN16(m1) = {{0xFF00, 0xFF00, 0xFF00, 0xFF00}};


		for (i = 8; i < to_read; i += 8) {
			v4hi v1, v2;
			v4hi vin;

			vin = *(v4hi*)buffer;
			v1 = __builtin_ia32_psllw(vin, 8);
			v2 = __builtin_ia32_psrlw(vin, 8);
			v1 = __builtin_ia32_pand(v1, m1.v);
			v2 = __builtin_ia32_pand(v2, m2.v);
			*(di*)buffer = __builtin_ia32_por(v1, v2);

			buffer += 8;
		}
__builtin_ia32_emms();

Alles anzeigen

Alles wie gesagt GPL, der "Prolog" zum MMX Fragment ist auch in LGPL verfügbar (siehe OpenAL).

Jetzt mitmachen!