Suche Silent Trimmer

    Also das sieht jetzt wirklich gut aus. :ja:

    Aber in einer Batch mit > Pipe zum Umleiten der Ausgabe kommt:

    Zitat

    KillSilence.exe - Fehler in Anwendung

    Die Ausnahme "unknown software exception" (0xc0000094) ist in der Anwendung an der Stelle 0x0040215a aufgetreten.

    so jetzt muß ich nur doch die den richtigen -v Wert finden. :D

    Und Lieber incredible es ist ja möglich, die Länge des Audios (Zeit oder Samples) nach FPS (PAL; NTSC; NTSC-FILM) auszurechnen, ist es denn auch möglich, wenn man einen Parameter zum -fps *** einbaut, dann nach dem Silence Cut auch dort zu schneiden? siehe Bitte auch mal das Bild an.

    Auf jeden FALL : lecker :)

    Zitat

    totalsize = t_waveinfo\data_ckSize
    bufferrest = t_waveinfo\data_ckSize % 1024 ; // Getting size of rest data which doesnt match 1MB buffer size
    buffercount = (t_waveinfo\data_ckSize-bufferrest) / 1024 ; // 1MB buffer

    Buffer = AllocateMemory(1024)


    Hier war wieder das gleiche Problem wie bei der 1024byte Bufferanzahl, da hatte ich ja von 0 bis Bufferanzahl gerechnet anstatt von 1 bis Bufferanzahl.
    Oben habe ich via Modulo die Rest-Bytes ausgerechnet, welche bei einem MOD1024 Buffer übrig bleiben. Diese wurden sodann auch von 0 bis Bufferrest ausgelesen, hier war ebenso 1 bis Bufferrest nötig.

    Demnach war deine letzte Datei in ihrer effektiven Audiodatengröße bestimmt nicht durch 1024 Teilbar, was ein 3sec wav z.B. wäre. Somit blieb ein Rest wo sodann der Fehler durchkam.

    Bitte testet nochmal diverse Wavs. Müsste jetzt stimmen.

    Was deine Angabe über den Waveheader mit 44 oder 46 Bytes angeht. Wie lässt sich das bei der Source herausfinden? Wo ist das in der WavHeaderstruktur vermerkt, damit das berücksichtigen kann.


    katjarella
    Eine ausgabe via Stdout ist noch nicht drin (ist nicht standard bei allen Konsoleapplikationen), da müste ich mal bei einigen Sourcen nachsehen, wie z.B. avs2yuv. Dort wird das unterstützt.

    Wie auch immer ... es findet ja nicht direkt ein Datenfluss statt, sondern vorab muss die Source auf Threshold abgesucht werden. Demnach muss ich mal nachsehen, wie das funktioniert. Piping war eh was, das ich mir mal generell ansehen wollte.

    Der -v Parameter hat keine Werte, er steht für "verbose" und gibt die kompletten Weaveheaderdaten im Command Window aus.
    Du meinst den Thresholdwert -t.
    Hier sieht es so aus, dass die Maximum Amplitude bei signed short 32768 beträgt. (2^16)


    LigH
    Ich muss mal nachsehen wie eine Umrechnung in db von Statten geht.
    Soviel ich weiss ist "-99db" demnach 0 und "0db" demnach 32768 (bei 16bit)?

    getestet:

    Code
    KillSilence.exe -v -t 0 -i audio.wav -o _temp0.wav > KillSilence.log
KillSilence.exe -v -t 0 -i audio.wav -o _temp0.wav >> KillSilence.log
KillSilence.exe -v -t 0 -i audio.wav -o _temp0.wav >nul 2> KillSilence.log
KillSilence.exe -v -t 0 -i audio.wav -o _temp0.wav | more > KillSilence.log

    Alles Absturz.

    Edit: habe extra mal ne Helper.exe erstellt, die StdoutRead macht... selbst da Absturz.

    Wie gibst Du den die Ausgaben aus?

    Via "Print()" was in PureBasic Strings im Konsolenfenster ausgibt.

    Ich glaube in C gibt es printf() und fprintf() wobei man beim zweiten einen Stream benennen kann, also stdout oder stderr.

    Schaue mir das am WE mal an, denn in Purebasic kann ich die MSVCRT direkt ansprechen und somit diese C Befehle nutzen, sowie die API Befehle AllocConsole() etc.

    Zitat von incredible

    Was deine Angabe über den Waveheader mit 44 oder 46 Bytes angeht. Wie lässt sich das bei der Source herausfinden? Wo ist das in der WavHeaderstruktur vermerkt, damit das berücksichtigen kann.


    "Der WAV-Header" ... gibt's eigentlich so nicht als starren Typ, der ist etwas komplizierter und flexibler, aber absichtlich normalerweise immer in der gleichen Struktur:

    - "RIFF"
    - Gesamtgröße (32 bit ohne Vorzeichen) ab hier...
    - RIFF-Unterformat: in unserem Fall "WAVE" (darf auch "AVI " oder "CDR " oder anderes sein)

    Ab hier dürfen verschiedene Chunks in eigentlich beliebiger Reihenfolge folgen! Jeder Chunk beginnt mit 4 Zeichen als Identifikator, und einem 32-bit-Wert, der die Länge speichert (kleine Ausnahme im "LIST"-Chunk); kennt der RIFF-Parser die Bedeutung des Chunks nicht, kann er um "Länge" Bytes weiterspringen und findet den nächsten Chunk dort.

    Für WAVE sind das normalerweise folgende Chunks:

    - "fmt " - Format-Details
    +- Größe des fmt-Chunks (mindestens 16 Bytes, evtl. mehr)
    +- Format (16 bit) - 1 für Integer-PCM, 3 für Float-PCM, ...
    +- Kanäle (16 bit), für mehr als 2 Kanäle wird aber der erweiterte Header WAVEFORMATEX empfohlen.
    +- Samples pro Sekunde (32 bit), unabhängig von der Kanalanzahl
    +- Durchschnittliche Bytes pro Sekunde (32 bit)
    +- Block-Ausrichtung (16 bit): kleinste Einheit an Daten
    +- Bits pro Sample (16 bit): Genauigkeit der Daten (evtl. nach dem Dekomprimieren)
    +- evtl.: Anzahl der folgenden formatspezifischen Daten
    +- evtl.: formatspezifische Daten zur Steuerung des Decoders

    evtl. (v.a. falls fmt.Format nicht 1 oder 3 ist):
    - "fact"
    +- Länge
    +- decoderspezifische Daten...

    - "data"
    +- Länge
    +- Audio-Daten

    Zitat

    Ich muss mal nachsehen wie eine Umrechnung in db von Statten geht.
    Soviel ich weiss ist "-99db" demnach 0 und "0db" demnach 32768 (bei 16bit)?


    Überhaupt nicht.

    "0 dB" hieße, dass die gesamte Aussteuerung zwischen Minimum und Maximum (bei 16 bit Integer: von -32768 bis 32767; bei normalisiertem Fließkomma: von -1,0 bis +1,0) innerhalb eines betrachteten kurzen Zeitraumes ausgenutzt wird. Eine bei 16 bit Integer kleinstmögliche Schwankung zwischen 0 und -1 entspräche etwa -96 dB. Glatt 0 wäre "-°° dB", nur ist "Unendlich" schwer als Zahl speicherbar.

    dB = 20 * lg |diff| { "lg" = "log[10]" }

    Für Vorzeichen übernehme ich hier keine Garantie...

    So, habe jetzt die Consolen Commandos via WinAPI erzeugt. Sind in PureBasic wie normale Befehle integriert, daher ging das fix.

    Problem war dass bei Purebasics default 'Print()' im Consolemode nicht in einen Stream geschrieben wird, so wie hier z.B. stdout benötigt wäre.

    Via AllocConsole(), GetStdHandle() und WriteFile() aus der Win32API funktionierts jetzt bei mir.

    D:\KillSilence.exe -i D:\MuteNoiseMute.wav -o D:\Trimmed.wav -v >> D:\log.txt

    ... erzeugt bei mir in der neuen 0.15 Version ein txt File mit folgendem Inhalt:

    Zitat von Katjarella

    Und Lieber incredible es ist ja möglich, die Länge des Audios (Zeit oder Samples) nach FPS (PAL; NTSC; NTSC-FILM) auszurechnen, ist es denn auch möglich, wenn man einen Parameter zum -fps *** einbaut, dann nach dem Silence Cut auch dort zu schneiden?


    Bedeutet es sollte ein -fps und ein -framestart -framestop mit integriert werden, wo dann audioframegenau geschnibbelt wird?

    Zitat von incredible

    So, habe jetzt die Consolen Commandos via WinAPI erzeugt. Sind in PureBasic wie normale Befehle integriert, daher ging das fix.

    :daumen: :daumen:

    Zitat von incredible

    Bedeutet es sollte ein -fps und ein -framestart -framestop mit integriert werden, wo dann audioframegenau geschnibbelt wird?


    naja ein -fps reicht eigentlich. Das also zum Bsp. bei -fps 25 die Länge des Audiostreams auf PAL Zeit geschnitten wird, aber bitte erst nach dem Silent löschen :) Ich bin mit mir aber noch nicht einig, ob man am Ende dann einfach hart abschneidet (ist glaube einfacher) oder bis zum nächsten möglichen Frame es mit Stille auffüllt.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden