Beiträge von 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:

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):

#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 wie gesagt GPL, der "Prolog" zum MMX Fragment ist auch in LGPL verfügbar (siehe OpenAL).

Nicht direkt dein Problem betreffend, aber beim gewerblichen Gebrauch sollte man auch keine Programme benutzen, die keine Lizenzen enthalten bzw. man sollte diese direkt beim Rechteinhaber (Dolby) erwerben. Insofern solltest du lieber in der kommerziellen Ecke suchen.

Ah danke, interessanter Trick!

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.

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

/***************************************************************************
 *   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;
}

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

Troublemaker ist mpalib. Hat ja schon bei mp3 als input Probs gemacht, also nicht verwunderlich, daß es bei mp2 auch raushaut. Wahrscheinlich ein kleiner däml Fehler, nur da ich cross nicht debuggen kann, habe ich auch aktuell keine Zeit dafür. Darum hatte ich ja schon angedeutet, daß ich zuerst versuchen werde - sobald ich Zeit habe - einen nativen compile unter Linux in Gang zu bekommen.

7ven

Für windows-only software implementiere ich nichts mehr.

Zitat von LigH

Ich gehe hier mehr von der Theorie dahinter aus. Ich weiß, welche Technologien grundsätzlich verwendet werden (Frequenzdomain-Konvertierung, Subband-Splittung, Psychoakustik-Modelle, Joint-Stereo-Varianten), und da sind MP3 und AC3 sehr ähnlich.

Nicht wirklich. ac3 (wie aac) basiert auf mDCT, mp3 arbeitet mit mDCT auf ner Filterbank - allein schon deswegen ist mp3 weniger effizient.

Ansonsten probier es mal mit dem alpha Paket von LigHs oder Daphys Seite.

Ach, der Punkt war schon gut. Ich werde versuchen, dran zu denken, das fürs nächste release einzubauen.

Zitat von bergh

Amen Brother ! <-----

BTW:96 ms Ob Plus oder Minus hört keine Sau.
Der Mensch nimmt (soll nehmen) erst Delays ab 200-300 ms wahr.
Also gar nix machen sollte am besten sein.

Wenn du engl O-Ton gewöhnt bist, können 100ms daneben durchaus auffallen - sind immerhin 2,5 Bilder daneben...

Wäre theor kein Problem, da es 2 bits gibt, die das regeln. Leider bin ich zur Zeit etwas im Streß und komme nciht dazu an Hac3 zu frickeln...

[a bit later] Habe mal kurz in den ac3enc code geguckt - ist wirklich trivial. Was mir dabei aufgefallen ist, ist daß offenbar falsche Werte für Downmix level für center und surround gesetzt werden. Statt jeweils -3 db werde -4,5 resp -6 db gesetzt... Findest jemand, daß ein ac3enc kodiertes 5.1 ac3 nach downmix auf 2 Kanäle komisch klingt? (zuwenig center und viel zuwenig surrounds?) Ich finde die flags schon etwas komisch, weiß aber nicht ob decoder die wirklich beachten oder stoisch mit -3db reinmischen...

libmmd.dll vergessen?

Wie ich schon schrieb alles über 20kHz ist nicht relevant, weil der DAC es rausfiltert.

Zitat von Kika

Sag' ich doch...

Damit meinte ich aber, daß die consumer ADCs nix taugen...zumindest weniger als die DACs...

Zitat von Kika

Das macht ja richtig Spaß...

Sorry, aber die Realität des Samplings ist eigentlich exakt so simpel, wie ich es dargestellt habe. Gesampled werden Schwingungsverläufe, was die repräsentieren ist dabei völlig uninteressant.

Was bei der Wiederherstellung der analogen Daten geschieht ist in Bezug auf das Sampling noch viel uninteressanter, weil es damit nämlich gar nichts zu tun hat.

Du kannst das eine aber nicht ohne das andere betrachten. Und "dumm" samplen kannst du halt auch nicht, wei ich angedeutet habe (again: du nimmt keine Punkte (= Nullausdehnung= auf). Sobald du Aussagen bzgl deiner Daten machen willst, reicht es nicht, sich auf das einfach sampling der Daten zu beziehen.

Und das Digitalisieren ist alles andere als triviel. Ich glaube sogar, daß DACs weiter entwickelt sind als ADC.

Zitat von Kika

Nähert sich jetzt die Tonfrequenz immer stärker der Samplingfrequenz an, bleiben pro Teil der Schwingung weniger Werte übrig. Ihr Verlauf kann also nicht mehr exakt erfasst werden. Nur: Was erfassen wir beim Samplen denn überhaupt? Amplitudenverläufe, sonst garnichts. Also keine Frequenzen oder so, sondern wirklich nur den Verlauf der Schwingung. Und da gibt es wirklich nur diese einfache Regel:

Jein, durch dein sampling machst du implizit eine Filterung: Du filterst alles raus, was größer samplingrate/2 ist. Nur wirst du aliasing haben, wenn du wirklich sowas drin hast und es nicht vorher explizit rausgefiltert hast.

Wirklich, dein Denkansatz ist ein Anfängerfehler. Denke es zuende. Die details, die du vermißt, sind wirlich Frequenzanteile, die von der Frequenz zu groß sind (oder zu kurz, was aber im Prinzip auf dasselbe raus kommt). Alles andere was dannnoch fehlt sind Amplituden der aufgenommenen Frequenzen.

Es geht hier nicht um die Rohdaten, die du hast, sondern umd ie Interpretation dessen. Du nimmst ja auch keineswegs Punkte auf, sondern Intervalle. Doch diese stellen eine Mittlung dar, die dann durch Punkte dargestellt werden. Aus diesen Punkten kann man ein Signal wiederherstellen. Doch das ist ja nicht mehr eindeutig.

Denke an eine Rechteckwelle. Wenn ich das noch richtig in Erinnerung habe, kommen hier unendlich hohe Frequenzen (->Sinus) vor, auch wenn deine Rechteckwelle an sich von bestimmter "Frequenz" ist. Doch wenn du die Rechteckwelle richtig (analog) setzt, kannst du die perfekt abtasten. Dennoch ist die Reproduktion im Idealfall (!!) *nicht* perfekt. Denn wenn die (mathematisch) perfekt wäre, wäre dein DAC mit hoher Warscheinlichkeit Mist, denn der glättet dann die samples nicht. Dh. in diesem Speziellfall arbeitet der DAC perfekt aber sonst immer generiert der einen Haufen unerwünschter Frequenzen hinzu.

Also muß ein DAC probieren nicht Rechteck, sondern Sinuswellen zu reproduzieren, darum wird der DAC auch idealerweise eine 22kHz Schwingung perfekt wiederherstellen können. (Die Realität sieht anders aus...) Doch mathematsich genügen tatsächlich diese zwei samples um 22 kHz perfekt wiederherstellen zu können! Mehr samples helfen nur einem (schlechten) DAC (und auch, daß wirklich die richtige Amplitude gespeichert wird...), aber nötig ist es nicht.

Darum ist ein guter DAC wichtig, denn der verfälscht letztenendlich das Ergebnis.

Zitat

Dinge wie Forurier- und Waveletanalyse bzw. -transformation kommen zum Tragen, wenn es darum geht, einen Codec einzusetzen, vorher aber nicht.

Richtig, aber dein Ohr arbeitet so und der DAC muß es für dein Ohr aufbereiten, insofern ist der Vergleich mit FT berechtigt, da der ja ein analoges Signal wiederherstellen muß aus diskreten Punkten. Du nimmst ja schließlich Frequenzen wahr. Umdiese in dienen Rohdaten zu finden, mußt du mit FT argumentieren.

Ergo: Digitale Signalverarbeitung ist ein sehr schwieriges Kapitel, da man von der analogen Welt in die digitale und wieder zurücktranfsormieren muß und zwischendurch noch nachdenken muß, was die Daten überhaupt repräsentieren.

Zitat

Hm, da fällt mir ein: Ich hab hier nen alten Drumcomputer stehen, wofür der Hersteller damit geworben hat, dass sie für Snare und Becken (sehr Obertonreich) keine Samples, sondern resynthetisierte Samples genommen haben.

Wenn der so alt ist, dann finde mal raus, mit wieviel Hz der gesampelt wurde. Evtl macht da resynth. Sinn.

Liebe Leute,ihr habt doch Ohren. Wenn ihr mir nciht glaubt, nimmt noch eine 19kHz Sinuswelle auf und spielt die ab. Dann sagt mir:

1) Hört ihr das Ding überhaupt noch? (Beim letzten Test, der einige Jahre her ist, konnte ich bis 19,5kHz höhren.)

2) Wenn ja, hörst du die ungewollte Amplitudenmodulation raus?

Wenn 1) und 2) ja, dann wechselt doch bitte ins DSD oder DVD-Audio Lager, denn ansonsten habe beide Formate keinerlei Daseinberechtigung, sondern sind nur Verscheißerung der Kundschaft...

Ach ja, was Kika's Argument bzgl des Auflösens ist: Das ist schlicht weg *falsch*, wie ich schon schrieb. Es ist nur ein Problem der Amplitude. Ich wette, wenn man schon was höhrt im oberen Frequenzbereich, dann ist es keine modulation, denn ich denke, daß sich das für unser Ohr gemittlet klingt. Mann könnte nun ausrechnen um wieviel die gemittlete Amplitude geringer ist, als man wollte und entsprechned per Filter in Frequenzabhängigkeit die Amplituden anpassen. Dann hättest du in der Tat eine saubere und (für unsere Ohren) amplitudengenaue Reproduktion. Doch das ist nciht durchgängig möglich, denn normalerweiseweise weißt du ja nicht, wie stark deine Frequenz abgesenkt wurde. bei 11kHz könnte der Ton schlimmstenfalls um die Hälfte abgesenkt werden. Doch ich denke bei Tönen aus der Realität hats du wenig reine Sinusschwingungen sondernimmer Überlagerungen und deswegen hast doch solche Probleme nicht wirklich (Wahrscheinlichkeit ist sehr gering).

Zitat von Sweeeet

Jo, ist schon klar. Nur kann man nicht von einer akzeptablen Aufnahme sprechen, wenn Frequenzen viel zu schwach repräsentiert werden.

Nur wird das bei 22kHz eh nicht ins Gewicht fallen, da das der DAC rausfiltert. Wegen anti-aliasing Filter wird ab 20kHz gefiltert und da ist die Representation des Signals schon brauchbar bzw die wenigsten werden klagen...

Zitat

In der Theorie funzt die Theorie. In der Praxis funzt die Theorie nicht.
Unendlich viele Frequenzen zu überlagern ist für Mathematiker kein Problem. Für Codecs schon.

Hat mit codecs weniger zu tun, sondern mit deiner Trafo in den Frequenzraum. Du mußt immer auswählen ob du bessere Lokalisation oder bessere Frequenzauflösung möchtest (erinnert an Heisenberg....). Also muß man einen guten Mittelweg finden, bzw hierfür gibt es bei den meisten codecs block-switching.

Wenn du mir nicht glaubst, daß Rauschen kein Problem auch in disktreten Fall ist, mach doch eine FFT und iFFT und wundere dich wie gut das Signal dem Original (natürlich nicht samplegenau) entspricht. Bzw neuere Codecs benutzen ja MDCT, aber Idee ist dieselbe.

Das Problem bei Rauschen ist nur die kompression, doch darum geht es hier gar nicht. Trafo in Frequenzraum und zurück ist an sich eine (im diskreten Fall beinahe) verlustfreie Operation, zumindest für unsere Ohren *ist* es verlustfrei (je nach eingestellter Fenstergröße).

(Wenn du genau mitdenkst, wirst du einen prinzipiellen Fehler in der Argumentation finden: Du darfst gar nicht erst mit digitalen Daten hantieren, denn deiner Meinung nach repräsentieren die weißes Rauschen nicht richtig. Ergo reicht schon der Vergleich zwsichen digitalen weißen Rauschen und analogen weißen Rauschen. Und den Unterschied (wenn man mal analoge Reproduktion derselben Güte finden möge) willst du tatsächlich hören können? :D)

Zitat von Sweeeet

Beispiel Sinus mit Schwingungsdauer L, Du hast ein Sample bei 0 und eins bei L/2, beidesmal mit dem Wert 0 --> Nix Ton gesamplet.
Wenn Du dagegen bei L/4 und 3L/4 gesamplet hättest, hättest Du 1 und -1 bekommen, was ja was völlig anderes ist.

Lese meine Anmerkung bzgl Amplitude. :zunge:

Zitat

Keine Ahnung wie moderne Codecs das machen, aber bei weißem Rauschen wird das mit der Superposition schwierig.

Na und? Dafür gibt es die Mathematik und die sagt, daß es wirklich so ist. (Ich hatte Vorlesungen Forurier- und Waveletanalysis im Hauptstudium und weiß wovon ich rede...)