Beiträge von akapuma

  • Warum resizen???

    Zitat von scharfis_brain

    akapuma, was machst DU, wenn Du deinen Encodeden Film zu einem Freund mitnimmst, und dieser keinen Player mit AR-Korrektur hat?

    AUsserdem mache ich sehr gerne 1CD-Rips und bei denen ist eine sehr hohe Aufloesung oft toedlich...
    704x288 sind aber sehr oft noch mit recht gutem ergebnis moeglich...


    Wenn ich den Film bei einem Freund ohne Player mit AR-Korrektur mitnehme, hoffe ich, daß dieser wenigstens ffdshow hat, damit kann man das AR auch einstellen, wenn auch viel komplizierter als z.B. mit dem BSPlayer.

    Und ein Stand-Alone hat eher eine AR-Korrektur, als das er QPel und 3 B-Frames und Vorbis im OGM-Container abspielen könnte. :D

    Natürlich ist bei 1CD-Rips eine sehr hohe Auflösung oft tödlich und auch gegen die Idee von MPEG4, Platz zu sparen. Oft ist aber nicht immer. Und wenn ich auf einer CD genug Platz habe, nehme ich auch die hohe Auflösung. Habe ich nicht genug Platz, dann resize ich auch "richtig" und lasse Zeilen weg. Beispiel:

    Ein Film im Format 2,35:1 hat 720x576 Pixel.
    Gecroppt bleiben noch 698x316 Pixel.

    Nun resize ich mit der maximal möglichen Auflösung, bei der es zu keiner Vergrößerung kommt. Da die X-Pixel durch 32 teilbar sein müssen, resize ich auf 96%. Dies ist in etwa Originalgröße.

    Resize ich "falsch", habe ich 672x304 Pixel.
    Resize ich "richtig", habe ich 672x208 Pixel.

    Bei einem 1CD-Rip ergibt das "falsche" resizen beim compressibility-check mit GKnot 52,5%. Dies ist meiner Meinung nach ausreichend. Da macht es mir nichts aus, auf der Bedienerleiste des BSPlayers einmal kurz beim Filmstart das richtige Aspektverhältnis zu wählen und habe dafür vertikal 304 anstatt 208 Pixel.

    Gruß

    akapuma

  • Pre-Gain doch nicht gut?

    Zitat

    Original von LigH
    Für das Abspielen von AC3-Audio brauchst du keinen AC3-Decoderfilter?!

    Das habe ich nochmals überprüft. Wenn ich den AC3Filter deaktiviere, übernimmt der intervideo Audio Decoder dessen Aufgabe. Das hatte ich zuerst garnicht bemerkt.

    Zitat

    Original von LigH
    Haarspalter... Du kannst Ogg Vorbis mit OggDec (oder z.B. auch OggDropXP) nach PCM-WAV decodieren und dann das WAV öffnen, oder du läßt die Decodierung beim Öffnen der Ogg-Datei vom Sampleeditor selber durchführen.

    Haarspalterei lag mir fern, wirklich! Hatte nur nochmals nachgefragt, weil ich alles richtig machen wollte.

    Zitat

    Original von LigH
    -ssrc(--twopass) ist Unsinn - das wird durch den "strömenden" Ablauf gar nicht unterstützt.

    Glaub ich Dir auf's Wort, machte mir auch keinen twopass-Eindruck. Hatte aber mal gelesen (von Dir?), daß "--rate 44100 --twopass --dither 3" die richtigen Einstellungen wären. Was mach ich denn nun? --twopass weglassen? Oder kann/soll/muß ich es doch irgendwie benutzen? Ich würde schon gerne von 48kHz auf 44,1kHz downsamplen!

    Zitat

    Original von LigH
    -boost(/b2=5) - bei 2-Kanal-Ton? Ja, kein Wunder, dass das übersteuert klingt! Bei Zweikanalton empfehle ich einen Faktor um etwa 3.0 bei Methode 1, wenn man es wirklich kräftig verstärken will; bei Mehrkanalton wäre für Methode 2 ein Faktor um 4.0 ausreichend. Meiner Meinung nach ist für Zweikanalton erstens Methode 2 die falsche, und zweitens Faktor 5.0 viel zu viel.

    Hier hast Du die Lösung gefunden! Allerdings hörte sich meine kleine AC3-Testdatei mit /b=3 auch nicht besser an. /b=2 war geringfügig besser, aber immer noch schlecht! Daher habe ich mal -boost weggelassen und den Azid-DRC mit -c normal und -c heavy probiert, beides war erfolgreich! Ich muß die Sache noch was austesten, möglicherweise wäre "heavy" für kleine PC-Lautsprecher besser. Das deutliche Clipping war bei beiden Einstellungen nicht zu hören!

    Nun habe ich zwar eine funktionierende Lösung gefunden, klar ist mir die Sache aber immer noch nicht. In meinem Post vom 03.10.03 um 1Uhr06 hatte ich beschrieben, wie ich die AC3 mit -boost( /b2=5) in erst eine WAV-Datei und die WAV dann in eine OGG-Datei transcodiert habe. Warum hat das nur geklappt? Außerdem habe ich schon oft /b2=5 für 2-Kanalton genommen, und habe nie Clipping festgestellt. Aber mit dem azid-DRC komm ich ja jetzt klar.

    Besteht nur noch die Frage, ob -ssrc auch ohne --twopass ordentlich verwendbar ist.

    Gruß

    akapuma

  • Pre-Gain doch nicht gut?

    Zitat

    Original von LigH
    aber ich kapiere irgendwie immer noch nicht, warum du der einzige bist, bei dem ausgerechnet Pre-Gain nicht funktionieren soll - denn theoretisch kann der ja gar nicht übersteuern


    Vielleicht fällt es ja nicht so oft auf, da:
    1: doch eher 5.1-AC3-Spuren verwendet werden
    2: geringeres Clipping ja nicht umbedingt auffallen muß

    Zitat

    Original von LigH
    Wenn also nicht mormalisierter (zu leiser) Ton bei dir ordentlich klingt und normalisierter (optimal ausgesteuerter) zu laut, dann kann ich mir das nur so erklären, dass irgendwo dazwischen noch ein verstärkender DirectShow-Filter hängt (vielleicht der TFM - oder wie der hieß...).


    Habe mal ein AC3-File abgespielt, folgende Filter sind beteiligt:

    Filtername - Filterdateiname - benötigt
    AC3 Parser Filter - MPG2SPLT.AX - ja
    AC3 Filter - AC3Filter.AX - nein
    MatrixMixer - Matrix_Mixer.ax - nein
    Channel Downmixer by Trombettworks - Channeldownmixer.ax - nein
    Default DirectSound Device - Quartz.dll - ja

    Die mit "ja" gekennzeichneten Filter wurden umbedingt benötigt. Die mit "nein" gekennzeichneten habe ich vorübergehend entfernt. Leider hat es nichts gebracht.

    Zitat

    Original von LigH
    Überprüfen ließe sich das, wenn du mal eine encodierte, normalisierte Tonspur wieder nach WAV decodierst und in einem Wave-Editor anschaust (in Frage kämen: CoolEdit, GoldWave, vielleicht auch Nero's Wave-Editor oder Audacity - die dürften alle MP3 und Ogg Vorbis decodieren können). Tritt dort auch eine Übersteuerung auf (optisch in der Wellenform), ist sie tatsächlich in der Datei; passiert es nur beim Anhören, dann funkt ein zusätzlich verstärkender DirectShow-Filter dazwischen.

    Du schreibst, die Tonspur wieder in WAV decodieren und dann anschauen. Danach steht, die Programme dürften auch Ogg Vorbis decodieren können. Das wiederspricht sich irgendwie, oder ich hab's nicht verstanden. Irgendwie sieht in Wave-Editoren bei mir alles gleich übersteuert aus, zumindest als ogg. wav hab ich hier noch nicht probiert.

    Bevor ich die Lösung kenne, gibt es eine Möglichkeit, eine Umwandlung AC3>WAV>OGG vorzunehmen und dabei BeSweet zur einmal zu starten?

    Gruß

    akapuma

  • Pre-Gain doch nicht gut?

    Hallo,

    ich glaube mal, die Ursache des Übels gefunden zu haben. Das Problem tritt bei mir nämlich nur bei 2-Kanal-AC3-Dateien auf, nicht aber bei 5-Kanal-AC3-Dateien. Daher stell ich jetzt mal ne Theorie auf:

    Bei 5-Kanal-Dateien kommt der Ton aus 5 Lautsprechern, bei 2-Kanal-Dateien nur aus 2 Lautsprechern. Bei gleicher Lautstärke aus jedem einzelnen Lautsprecher kommt bei 5-Kanal-Ton also 2,5 mal soviel raus. Bei der Normalisierung des 2-Kanal-Ton's denkt die Normalisierung daher, der Ton könnte 2,5 mal so laut sein und macht ihn deshalb 2,5 mal lauter. 2,5x lauter entspricht etwa 7,96dB. Nun werden die 2 einzelnen Lautsprecher um ca. 7,96dB verstärkt. Da diese aber nicht zu leise waren, kommt es zu extremem Clipping, der Ton hört sich schrecklich an. So sahen meine BeSweet-Parameter aus:

    -core( -input "%input%" -output "%output%" -logfile "%log%" ) -ota( -norm 0.97 ) -azid( -L -3dB -c none -s stereo -n1 -f1 ) -ssrc( --rate 44100 --twopass --dither 3 ) -boost( /b2=5 ) -ogg( -q 0.000 ) -profile( %version% )

    Zur Normalisierung steht in der LOG-Datei:

    Input : C:\Test\Test.ac3
    Output: C:\Test\Test.ogg
    Floating-Point Process: Yes
    Overall Track Gain: 10.132dB


    Als Abhilfe habe ich nun zuerst aus dem 2-Kanal-AC3-Ton einen WAV-2-Kanalton erzeugt:

    -core( -input "%input%" -output "%output%" -2ch -logfile "%log%" ) -azid( -L -3dB -c none -s stereo -n1 -f1 -F wav32 ) -ssrc( --rate 44100 --twopass --dither 3 ) -boost( /b2=5 ) -profile( %version% )

    Zur Normalisierung steht natürlich nichts in der Log-Datei, da ja nichts normalisiert wurde:

    Input : C:\Test\Test.ac3
    Output: C:\Test\Test.WAV
    Floating-Point Process: No


    Nun habe ich den WAV-2-Kanalton mit Normalisierung in einen ogg-Ton transcodiert. Hier rafft die Normalisierung, daß der Eingang nur ein 2-Kanal-Ton ist:

    -core( -input "%input%" -output "%output%" -logfilea "%log%" ) -ota( -norm 0.97 ) -ogg( -q 0.000 ) -profile( %version% )

    Input : C:\Test\Test.wav
    Output: C:\Test\Test.ogg
    Floating-Point Process: Yes
    Overall Track Gain: 2.855dB

    Ergebnis von AC3 => WAV => OGG: Perfekt, kein Clipping, alles Klasse. Subtrahiert man nun die beiden von BeSweet verwendeten Normalisierungen, ergibt das 10,132dB-2,855dB=7,277dB. Nach meiner Theorie müßten es 7,96dB sein, was zuerst zuviel verstärkt wurde, die Werte passen also gut zusammen.

    Diese Probleme müßte an sich JEDER haben, der einen 2-Kanal-AC3-Ton Normalisiert!

    Trotzdem habe ich noch 2 Fragen:

    1. Warum steht bei der Umwandlung von AC3 in WAV Floating-Point Process: No? Ist das normal?
    2. Bei der Methode AC3 => WAV => OGG muß ich BeSweet zweimal starten. Kann ich die beiden Schritte zusammenfassen, aber so, daß auch tatsächlich ein WAV-File gebildet wird. Wäre eine sehr willkommene Erleichterung!

    Gruß

    akapuma

    PS:

    Wer jetzt Schreiben will, daß -q 0.000 zu wenig ist: Ich will KEINEN sourround-Ton, sondern lediglich einen 64kbps-Stereoton. Dafür ist -q 0.000 richtig. Sourround oder Stereo hat auch keinen Einfluß auf das Problem.

    Ich weiß, daß der Parameter -f1 bei -azid für ein 2-Kanal-AC3-Ton als Eingangsgröße unnötig ist, ich suche aber eine "Universallösung", die 2- und 5-Kanal-Ton transcodieren kann. -f1 hat auch nichts mit dem Problem zu tun.

  • Pre-Gain doch nicht gut?

    Tja, die Sache läuft noch schlechter, als ich dachte, denn hybridgain tut's auch nicht, wenn ich zu Ende transcodiere. Als Anlage füge ich mal mein Problem bei:

    TEST.AC3
    Das Original, klar und sauber.

    TEST1.OGG
    Normalisierung: Pregain-Normalisiert mit -g 0.97
    Log-Datei: Overall Track Gain: 12.519dB
    Ergebnis: Clipping, total übersteuert, absoluter Mist.

    TEST2.OGG
    Normalisierung: -hybridgain
    Log-Datei: vorn: PostGain normalize to : 0.97, hinten: Gain of 8.5dB had been asserted to file.
    Ergebnis: Clipping, total übersteuert, absoluter Mist.

    TEST3.OGG
    Normalisierung: nichts (garnichts!)
    Log-Datei: Natürlich nichts zur Normalisierung
    Ergebnis: OK!!!!!!!!!!!!!!!!!!!!!!!!

    Es geht mir hier nur um die Normalisierung, nicht um die anderen Parameter. Bei TEST3 hat's mit denen ja auch geklappt.

    Was kann ich hieraus für einen Schluß ziehen? Nicht mehr normalisieren? Daß kann's ja wohl nicht sein! Daher gibt's nur eins:

    Bitte helft mir!

    Alle beschriebenen Dateien samt LOG's im Anhang.

    Danke

    akapuma

  • Warum resizen???

    Zitat

    Original von scharfis_brain
    Also werden aus 576 pixeln 396 pixel.

    Du verschenkst so 31% der vertikalen Auflösung. Oder, anders ausgedrückt, ohne Reduktion der v-Auflösung hättest Du 45% mehr vertikale Auflösung.

    Da behalte ich lieber die Eierköppe und stelle das Aspektverhältnis am Player ein. Ich halte es nicht für zu Aufwendig, bei 90min Film z.B. beim BSPlayer am Anfang mal kurz auf den leicht zugänglichen Button "Change Aspect Ratio Cycle" zu klicken.

    Aber das ist natürlich Ansichtssache.

    Gruß

    akapuma

  • VHQ @ Selurs Guide

    Zitat

    Original von bond
    ist zwar der falsche thread aber qpel kannst du sowohl bei 2cds als auch bei 1cd rips aktivieren -> qpel bringt einem ein viel schärferes bild ohne die compressibility stark zu beeinflussen...

    Kann ich bestätigen. Habe mal eine verrauschte DVD auf eine CD mit und ohne qpel gerippt. Ergebnis: Mit qpel war es wesentlich schärfer. Dies konnte man schon so sehen, auch ohne direkten Vergleich. Trotz verrauschter Quelle konnte ich die gelegentlich hier bei qpel beschriebenen Artefakte nicht erkennen. Daher benutze ich, trotz niedriger Datenraten bei 1CD rips, gerne qpel.

    Gruß

    akapuma

  • Warum resizen???

    Hallo,

    bin nicht der Meinung wie scharfis_brain, daß resized werden muß, um das richtige Aspektverhältnis zu erhalten. Das richtige Aspektverhältnis macht der Gordianknot nach Anwahl von "Smart Crop All", d.h., er croppt (schneidet) etwas anders.

    Der Grund für's resizen bei liegt daran, daß die Breiten-Pixelanzahl bei XviD durch 32 und die Höhen-Pixelanzahl durch 16 teilbar sein muß. Andere Werte komprimieren nicht richtig! Für divx geht, glaube ich, auch jeweils 16.

    Croppen (schneiden) halte ich an allen 4 Seiten für wichtig, da:
    - sonst die schwarzen Streifen mitcodiert werden müssen
    - unsaubere Seiten, z.B. rechts und links, nicht nur häßlich sind, sondern auch unnütz Bandbreite verbrauchen
    - ein paar Pixel mehr weggecroppt auch nicht stören

    Und da dann bei mpeg-4 die Pixelzahlen halt nicht mehr durch 16 bzw. 32 teilbar sind, resized der GKnot dann eben.

    Gruß

    akapuma

  • Pre-Gain doch nicht gut?

    Hallo,

    ich habe ein Problem mit der Normalisierung.

    Bisher war ich ein großer Fan von Pre-Gain (BeSweet: -ota( -norm 0.97) )
    Ich sehe in PreGain folgende Vorteile:
    1: Echtes 2-Pass-Verfahren, müßte besonders genau sein.
    2: Die ermittelte Verstärkung wird während der Transcodierung angewandt, die Daten werden daher wirklich auf's Maximum (FullScale) skaliert und nicht erst nachher beim Abspielen durch einen PostGain-Wert skaliert.
    3: Da PostGain immer 0dB bzw. Faktor 1 ist, macht es nichts, wenn der Player PostGain nicht unterstützt. Habe da z.B. WinAmp im Verdacht.

    Nun kommt das Problem:

    Beim Transcodieren eines AC3-Ton's ermittelt Pre-Gain "Overall Track Gain: 10.132dB". Nehme ich andere Parameter, z.B. --maximize bei -azid oder --normalize bei -ssrc wird ein Overall Track Gain: 10.397dB ermittelt. 10.397 ist auf 100% skaliert, 10.132 auf 97%. Beides ist viel zu viel!! Der Ton ist verzerrt!

    Nehme ich nun hybridgain (BeSweet: -ota (-hybridgain) ), steht in der Log-Datei "PostGain normalize to : 0.97". Hiermit ist der Ton in Ordnung.

    Wie kommt das nur? Warum macht PreGain was falsch, hybridgain aber nicht?

    Danke

    akapuma

  • Dynamikkompr./Boost mit BeSweet

    Hallo,

    hab mal 2 Fragen zur Dynamikkompression mit Besweet:

    Es gibt 3 Algorithmen hierfür, /b=, /b2= und /b2=.

    Frage 1: Worin unterscheiden diese sich, außer im Autor, eher in der Wirkung? Oder welcher ist wofür am geeignetsten?

    Frage 2: Welche Wirkung haben die Faktoren dahinter? Gibt es da ne allgemeingültige Regel wie 3=wenig, 4=normal und 5=stark?

    Ich möchte aus AC3 Vorbis-(Stereo)-Dateien mit 64kpbs machen.

    Danke

    akapuma

  • Ton mit BeSweet normalisieren

    Hallo LigH,

    herzlichen Dank für Deine Antwort. Aber so leicht scheint es leider nicht zu sein.

    Ich habe aus einem Spielfilm eine 5.1-AC3-Tonspur extrahiert und spiele diese mit dem Windows Media Player 6.4 ab. Über "Datei" "Eigenschaften" "Erweitert" "AC3Filter" "Eigenschaften" komme ich an das AC3-Filter, das diesen Ton decodiert. Dort gibt es im Feld Gains (siehe Bild) die 3 Schieberegler "LFE" "Voice" und "Sourround". Diese 3 Regler sind durch das angekreuzte BSI geblockt, können also nicht verschoben werden. Die AC3Filter-Anleitung beschreibt den Regler "Voice" mit "Voice - center channel gain level (dialogue channel)". Am Bild sieht man, daß dieser etwas unter null steht, es könnten -4dB sein. Der Regler Voice scheint mir also mit der -azid-dialog-normalisation-reduction identisch zu sein. Sowohl das GAINS-Fenster als auch die BeSweet-AZID-Anleitung verwenden hierfür auch einen BSI-Wert.

    Löse ich nun den "Voice"-Regler (Kreuz darunter weg) und schiebe diesen auf minimum, ist alles gesprochene fast weg. Schiebe ich den Regler ganz hoch, ist das gesprochene gegenüber dem Rest viel zu laut. Da der Regler normalerwise auf ca. -4dB steht, wird das gesprochene also etwas leiser wiedergegeben, als wenn er auf 0 stehen würde.

    Daher denke ich, daß gesprochenes um 4dB zu laut wiedergegeben wird, wenn ich den Parameter -n nicht verwende. Also muß ich doch -azid(...-n1) nehmen, oder? Wenn sich der mit azid decodierte Ton genau so anhören soll, als wenn ich direkt AC3 höre, kann es doch nur eine richtige Lösung geben.

    Wer weiß was? Hilfe!

    Danke

    akapuma