Beiträge von DarkAvenger

    Ich stimme LigH zu.
    damit man die "höhere Geschwindigkeit" (24p --> 25i) nicht hört.


    *Mööp*, stimmt nicht. Ich höre sehr wohl, daß die Stimmen höher sind. (I.a. werden die Tonspuren wirklich beschleunigt und nicht die Frequenzhöhen beibehalten.) Wenn man die Synchronstimmen aus dem TV aus Serien kennt (Bsp Star Trek), oder mal die englischen Spuren von PAL und NTSC vergleicht, fällt das sehr wohl auf. (Habe mal gelesen, soll einen ~Halbtonschritt ausmachen, muß also kein goldenes Ohr haben...)


    Ich halte das nicht für wahnsinnig schwierig, wenn man ein Resampling machen will. Dafür gibt es hinreichend gute Programme. Nur wenn man einen aufweniger gemachten Speed-up hat, wo die Freuenzhöhen beibehalten wurden (macht man das überhaupt?), den man verlangsamen will, ohne, daß die Stimmen nun dunkler klingen, hat man ein Problem...

    LigH


    Ließe sich feststellen, ab welcher Rev der Fehler passiert? Mit "svn up -r NUMMER" läßt sich eine spezielle Revision ziehen. Dann ließe sich der fehlerhafte commit schnell ausmachen.


    Ich glaube rev 153 ist die erste fehlerhafte und ich bin es schuld. :-/


    OK, bug ist gefixt. Rev 212 sollte wieder sauberen Klang produzieren.


    Allerdings, was mir aufgefallen ist: Mappt aften die Kanäle richtig? xine psielt die nämlich falch ab, wenn ich das mit der originalen ac5 Testdatei vergleiche. Da aber schon aften 0.05 dieses Verhalten zeigt, kann es nicht an mir liegen. ;-)

    So die SSE(3) Routine aus dem Vorbis Lancer Projekt ist nun drin und funktioniert nach meinen Test unter Windows und Linux, wobei ich unter Windows nur MSYS/MinGW mit gcc 3.4.5 getestet habe. Unter Windows benötigt man CMake vom CVS, was aber nicht schwer zu bauen ist.

    Es sollte nun mittels CMake möglich sein eine aften.dll zu erzeugen. Wäre gut, wenn das mal jemand testen könnte. Man könnte dann immer noch eine wrapper-dll drumherum basteln, wenn man's braucht... und da aften LGPL ist, gibts auch keine Probs mit der Lizenz.

    LigH


    An HeadAC3he habe ich schon lange nicht mehr weitergearbeitet, und könnte auch dauern... Du darfst aber mal raten, wer für den Großteil der Geschwindkeitssteigerung von Aften verantwortlich ist. :) Auf der devel List findet sich auch ncoh ein Patch, der u.a. eine SSE optimierte mdct enthält und Aften nochmal um die 9% schneller macht (ohne Qualitätsverlust natürlich).

    Man könnte mit ac3enc auch sinnvolles VBR erzeugen.


    Man gucke sich die Schleife an, in der bit_alloc aufgrufen wird und die entsprechende Prozedur. Die Qualität könnte man mittels csnroffst einstellen. Mein müßte den code nur insofern modifizieren, daß die die framesize der snr angepaßt wird und nicht umgekehrt, wie das für cbr geschieht. Das sollte mit moderaten C Kentnissen zu bewerkstelligen sein.

    Zitat von paddy78

    hmmm also ich gehe mal davon aus das sauber demuxt wurde. wenn ich die files mit azid abspiele, dann meldet er ständig: W1: Found sync after 18 bytes.


    Das spricht eher dafür, daß da irgendwas nicht ganz sauber ist. Womit hast du aufgezeichnet? Kannst du mit etwas anderem aufzeichnen? Kannst du mit etwas anderem demuxen?


    Mußt halt alle möglichen Fehlerquellen versuchen zu eliminieren.

    Leider habe ich (mal wieder) keine email notification bekommen. Darum wären in zukunft emails statt PMs besser...


    Aber zum Thema: Leider habe ich auch null Ahnung, wurde auch sauber demuxt? Denn hier könnte ja auch ein Fehler liegen. Ansonsten wurde die ac3 frame Größe richtig ermittelt? Evtl sind ja keine Daten hinten, sondern mittlen drin hinzugefügt worden. Es gibt ja ein Möglichkeit extra Daten anzuhängen. Was passiert, wenn du den stream etwa mit liba52 oder azid dekodieren willst (oder scan mit HeadAC3he)? Spuckt der Fehler oder gehts ohne Probs? Wenn es keine Probs gibt, liegt der Fehler eher beim Anwender. ;)

    Zitat von LigH


    Die "höherwertige 20 bit"-Maske 0xFFFFF000 sähe also in einzelnen Bytes so aus, wie sie hier zu lesen ist: FF - FF - F0 - 00


    Incredible hat $000FFFFF. Wenn dies dasselbe bedeutet wie 0x000FFFFF, hast du etwas geschrieben, was mit Incredibles Text wenig zu tun hat. Oder ich habe falsch verstanden was du meinst, redest du vom Resultat oder der Maske? Es ist denkbar schlecht FF FF FF FF als Input Beispiel zu verwenden... Ah, ich denke du meinst doch dasselbe, nur finde ich die Schreibwiese mit 0x... eindeutiger. Das FF - FF - F0 - 00 scheint anzudeuten, wie die Daten im WAVE zu liegen und dann stimmt das nicht mehr mit 0xFFFFF000 überein, weil FF das niederwertigste byte wäre.


    Zitat


    Und ich schiebe nicht links und rechts hin und her, sondern alles auf 32 bit.


    Ja, aber wie geschrieben, könnte die die Maskiererei Probleme mit signed Werten machen. Außderdem könnte die Maske an sich falsch sein - je nachdem wie man die 32 bit temp Variable füllt.

    Waves sind in Intel Order (schon mal Windows auf 'nem Mac gesehen? ;)).


    LigH


    Du hast es immer noch nicht so ganz mit Motorola und Intel Order raus. ;)


    Wenn im Wave steht 1F 2F 3F 4F, steht bei intel 0x4F3F2F1F und bei big endian 0x1F2F3F4F (also wenn man Daten in char *buf hätte und einfach int i=*(int*)buf machen würde). Denmach würde and mit 0x000FFFFF die falsche Operation bei intel order sein, wenn man die nierderwertigen bits löschen möchte, weil man dann 0x000F2F1F bekäme. Man muß mit 0xFFFFF000 "and"en und dann shiften (EDIT:nein kann auch nicht stimmen, s.u.). Ich denke aber das sign könnte noch Probleme machen.


    Ach, ich habe mal im meine Routine geguckt bei 24bit int shifte ich einfach um 8 nach rechts und dann wieder zurück nach links. Dann wird sign korrekt mitgeschleppt. (Sonst, wenn du das byte löschen willst per AND, mußt du dann das sign bit extrahiern und sign extension mache - aua.) Ich nehme an bei 20bit machst du (x<<8)>>12.

    Zitat von feelfree


    Hier: http://forum.gleitz.info/showthread.php?t=26858 schreibst Du, dass ein ac3-Frame immer 1536 Samples/Kanal lang sei. Das kann irgendwie nicht ganz stimmen. Mein Test-ac3 hier hat 1792 Bytes/Frame, ist also bei 448kbps genau 32ms lang. Wo finde ich denn die Spezifikation des ac3-Headers, um rauszukriegen, welche Bitrate/Framegröße so ein ac3 denn hat?


    Rechne doch einfach mal 48000/1536....und das hat nichts mit der bitrate zu tun. bytes/frame (komprimiert) interessieren auch nicht. Ich rede von unkomprimierten samples.


    Sie specs findest du unter atsc.org als a/52.



    Zitat


    Und HeadAc3He hat da ein 44.1kHz WAV daraus gemacht! Misstrauisch


    Du kannst ja versuchen den header auf 48kHz zu patchen (nicht resamplen!). Sinnd er 44,1kHz sind, damit man das auf CD machen kann.


    Zitat


    Leider habe ich auch noch keinen Weg gefunden, 48kHz WAVs auf dem Hifidelio bitgenau über den SPDIF wieder auszugeben, das geht vorerst also leider nicht.


    Das ist aber blöd. Kann er keine 48kHz ausgeben?


    Zitat


    Ich werde jetzt nochmal testen was passiert, wenn man nicht auf 1536 Samples auffüllt, sondern nur auf 1411,2 - naja, werd' wohl auf 1412 runden :-))


    Wird in die Hose gehen, auf die Idee war ich auch schon gekommen.

    Ach OK, dann bau ein 48Khz WAV, füge vor jedem ac3 frame
    {0x72,0xF8,0x1F,0x4E,0x01,0x00,0x00,0x38} ein und fülle 2 * 1536 * 2 - 8 bytes mit 00en auf. Das müßte funktionieren. Die 8 Werte habe ich durch reverse engineering erhalten, wirklich verstanden hatte ich die nicht ganz.


    Allerdings muß das Verpacken nciht mit jedem receiver funkt. Deiner tut es wohl, weil der dem vermeintlichen PCM nicht ganz traut. ;)