Suche Silent Trimmer

  • 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.

  • WAV ist eine Microsoft-Erfindung. Microsoft-Betriebssysteme laufen auf intel-Prozessoren. Also wird intel-Bytereihenfolge verwendet.

    16 bit:

    [links 0-7] [links 8-15] [rechts 0-7] [rechts 8-15]

    24 bit:

    [links 0-7] [links 8-15] [links 16-23] [rechts 0-7] [rechts 8-15] [rechts 16-23]

    20 bit = "24 bit mit reduzierter Genauigkeit":

    [links 0-3 * 16] [links 4-11] [links 12-19] [rechts 0-3 * 16] [rechts 4-11] [rechts 12-19]

    Willst du vergleichbare Werte, müsstest du im Grunde alle Sample-Arten immer auf 32-bit LongInt multiplizieren (vor allem weil das höchstwertige Bit ja das Vorzeichen ist). Denn es könnte ja auch noch 32-bit-WAV auf dich zukommen, theoretisch. 20- und 24-bit-Samples also um 8 bit auf 32 bit, 16-bit-Samples um 16 bit auf 32 bit.

    Solange du nur auf "= 0" prüfst, ist das Nebensache. Erlaubst du aber einen gewissen Minimalpegel, dann wirst du unter Umständen eine komplett einheitliche Regelung brauchen.

    Es gibt übrigens auch Fließkomma-Samples (Codec 0x0003).
    __

    Diskutiert mal weniger über "20 bit WAV"; 20 bit PCM auf DVD unterscheidet sich dermaßen krass in seiner Struktur, dass hier ein bloßes Umsortieren ganzer Bytes gar nicht ausreichte, hier musste ich in "Twen" gar Halbbytes verschieben. In WAV-Dateien wird "20 bit" verwaltet als "24 bit mit den 4 niederwertigsten bits = 0" (also durchschnittlich 6 Bytes pro Sample bei Stereo), auf DVD dagegen sind die niederwertigsten 4 bits von je zwei Samples zweier Kanäle miteinender verschränkt und gemischt, um wirklich auf nur durchschnittlich 5 Bytes pro Stereo-Sample zu kommen.

    In der "Dokumentation" von Twen habe ich das "grafisch" verdeutlicht.
    __

    @ DarkAvenger:

    In der Datei steht nacheinander: 1F 2F 3F 4F

    Motorola interpretiert an der kleineren Adresse die höhere Wertigkeit (menschenlesbare Reihenfolge), also:

    256^3 * 1F + 256^2 * 2F + 256^1 * 3F + 256^0 * 4F

    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

    intel interpretiert an der kleineren Adresse die niedrigere Wertigkeit (adressenorientierte Reihenfolge), also:

    256^0 * 1F + 256^1 * 2F + 256^2 * 3F + 256^3 * 4F

    Die "höherwertige 20 bit"-Maske 0xFFFFF000 sähe also in einzelnen Bytes anders herum aus: 00 - F0 - FF - FF; allerdings würde niemand die Maske in einzelnen Bytes anwenden, sondern als LongInt auf 4 Bytes komplett.

    Was habe ich nun falsch verstanden?

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

  • Zitat von katjarella

    Ach LigH, wenn Du gerade dabei bist, kannst Du auch nen WAV Joiner bauen, genauso wie der letzte FILE Joiner mit Liste und so?

    LigH
    alle Quellen:
    Channels mode 2 Channels
    Sampling Frec 48000
    Bits of Prec. 16

    Aufruf:
    WaveJoin.exe join.lst output.wav chapters.txt

    join.lst:

    Code
    &lt; TEST001.wavmute.wav&lt; TEST002.wavmute.wav&lt; TEST003.wavmute.wav&lt; TEST004.wavmute.wav

    Rückgabe:

    Code
    WaveJoin - 2006-02 by LigHList file loaded; checking files..."&lt; TEST001.wav" does not exist; trying OEM => ANSI conversion."&lt; TEST001.wav" does not exist either; giving up.

    habsch nur aus sicherheit gemacht!!!

    ------------------------------------------

    join.lst:

    Code
    &lt;TEST001.wavmute.wav&lt;TEST002.wavmute.wav&lt;TEST003.wavmute.wav&lt;TEST004.wavmute.wav

    Rückgabe:

    Code
    WaveJoin - 2006-02 by LigHList file loaded; checking files..."&lt;TEST001.wav" found."mute.wav" found."&lt;TEST002.wav" found."mute.wav" found."&lt;TEST003.wav" found."mute.wav" found."&lt;TEST004.wav" found."mute.wav" found.output.wav+ &lt;TEST001.wav

    Und dann habsch 100% CPU und eine output.wav mit 1kb, keine chapters.txt und das Programm hängt und nix passiert

    Filemon:

    kann es seon, das er nach &lt;TEST001.wav sucht??????

  • 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.

  • @ katjarella:

    Größer, nicht kleiner!

    Code
    >TEST001.wav
    mute.wav
    >TEST002.wav
    mute.wav
    >TEST003.wav
    mute.wav
    >TEST004.wav
    mute.wav


    __

    @ incredible:

    Wenn die Ursprungsdatei gar keine Stille hatte, sollte die Kopie genauso lang sein wie das Original. Sie wird aber 1026 Bytes länger (mit Nullen angehängt) - und die Datei ist dadurch länger, als der Header meldet...

  • incredible
    Irgendwas stimmt net.

    Code
    TESTSIGNAL3sec.wav		= TotalSamples=144000	Duration=00:00:03.000
    mute.wav			= TotalSamples=96000	Duration=00:00:02.000
    MUTE_TESTSIGNAL3sec_MUTE.wav	= TotalSamples=336000	Duration=00:00:07.000
    TESTSIGNAL3sec_CUT.wav		= TotalSamples=143997	Duration=00:00:03.005

    wie kann es sein, das bei weniger Samples, mehr Zeit raus kommt?

    anbei das Testsignal und die mute.wav


    MUTE_TESTSIGNAL3sec_MUTE.wav wurde so erzeugt:
    sox.exe mute.wav TESTSIGNAL3sec.wav mute.wav MUTE_TESTSIGNAL3sec_MUTE.wav

    TESTSIGNAL3sec_CUT.wav wurde so erzeugt:
    KillSilence.exe -v -t 0 -i MUTE_TESTSIGNAL3sec_MUTE.wav -o TESTSIGNAL3sec_CUT.wav

  • Glaube habe den Fehler gefunden ...

    Wenn man in meine Sourcen schaut, dann sieht man die WaveHeader Struktur:

    Code
    Structure WAVEheader    ckid.b[4];            /* chunk id 'RIFF' */    ckSize.l;             /* chunk size */    wave_ckID.b[4];       /* wave chunk id 'WAVE' */    fmt_ckID.b[4];        /* format chunk id 'fmt ' */    fmt_ckSize.l;         /* format chunk size */    formatTag.w;          /* format tag currently pcm */    nChannels.w;          /* number of channels */    nSamplesPerSec.l;     /* sample rate in hz */    nAvgBytesPerSec.l;    /* average bytes per second */    nBlockAlign.w;        /* number of bytes per sample */    nBitsPerSample.w;     /* number of bits in a sample */    data_ckID.b[4];       /* data chunk id 'data' */    data_ckSize.l;        /* length of data chunk */EndStructure



    Habe einfach den SourceWaveheader am Anfang des Target-Wavs gesetzt und vorher die entsprechenden Werte auf die des neuen Wavs gesetzt, also data_cksize z.B.

    Code
    ; // copying the source waveheader to a target weaveheader strcuture
    CopyMemory(@s_waveinfo, @t_waveinfo.WAVEheader, SizeOf(WAVEheader))
    
    ; // assigning target specific values to the target wave header
    t_waveinfo\data_ckSize = stop-start
    t_waveinfo\ckSize      = t_waveinfo\data_ckSize+36
    
    ; // writing the weaveheader to the target file
    UseFile(#Target)
    WriteData(@t_waveinfo,SizeOf(WAVEheader))

    Als data_cksize Wert habe ich also 'stop-start' genutzt, sind demnach die Bytes in der Source welche den Threshold erreicht haben.
    Ich denke bei dem Wert 'stop' zeigt bereits auf das nächste byte in der source.
    Ist genauso wie in C, wenn ich mit fread() ein file-byte gelesen haben, so zeigt mir ftell() den Zeiger zum nächsten byte, jedoch nicht den der gerade gelesen wurde.

    demnach müsste die target länge aus 'stop-start-1' bestehen, was sodann als data_cksize in den Target WaveHeader übernommen werden müsste.
    Ich denke genau der Wert eines byte zuviel macht eben bei Katjarella die paar Mikrosekunden mehr in der Anzeige aus.
    Die tatsächlichen übernommenen Bytes in die Target-Wav müssten aber stimmen - in Werten und auch Anzahl.

  • Zitat von incredible

    bei Katjarella die paar Mikrosekunden mehr

    :( Mikrosekunden, sind nach Millionen davon schon VIEL zu VIEL :D

    ne im Ernst... Du darfst nicht vergessen, das ich nach dem Parsing noch nach 23;25;29FPS etc umrechnen muß und mehrere Waves hintereinander kommen. Da kann es dann echt zu verschiebungen kommen. Gelle.

    Lieber incredible und wenn das Teil dann schön funkt, kommt der nächste Schritt :ani_lol: hab da echt noch geniale Einfälle. Ich hoffe Du rennst jetzt net wech.

  • Zitat

    Mikrosekunden, sind nach Millionen davon schon VIEL zu VIEL

    Die "paar" bezog sich ja nicht auf ein "egal", sondern um eine Anzahl, die es klarerweise in einem stable Release zu vermeiden gilt.

    Zitat

    Ich hoffe Du rennst jetzt net wech.

    kommt auf die Einfälle an.
    Erstmal das Ding mit den 20/24 bit support ans Laufen bringen, dann das Nächste ....

    Der ganze Zeitvertreib hat hauptsächlich den kleinen [Contenance/OFF] *Geilheitsfaktor* inne, WAVs im Bereich Programmierung in ihren Details zu begreifen.

    Schon mal überlegt, dich mit einem Application Devel. Environm. auseinanderzusetzen (basierend auf C, Pascal oder Basic)?
    Wenn ich da deine AutoIt-Arien sehe, dann denke ich mir, könnte das für dich interessanter (und effektiver) sein ...

  • So, habe nun selber ein "stille" wave mit 60sec erzeugt (Audition), sowie ein 120sec "pink noise" wave. Alle in 16bit, stereo, 480000hz.

    Sodann in Audition die o.g. in der Reihenfolge stille-noise-stille aneinandergesetzt. Resultat (logischerweise) 4sec total.

    Durch die (nun) bug-fixed KillSilence 1.02 Binary geschickt und das Resultat ist hier:
    (Via Auditions "Welleneigenschaften")

    --------------------------------------------------------------------------------

    Dateiname: Trimmed.wav (angefügte Stille(n) wurden via KillSilence1.02 getrimmt)
    Ordner: D:
    Dateityp: 48000 Hz, 16-Bit, Stereo
    Unkomprimierte Größe: 21.97 MB (23.040.000 bytes)
    Dateiformat: Windows PCM
    Windows PCM
    Größe auf Disk: 21.97 MB (23.041.068,00 bytes)
    Zuletzt gesp. (lokal): 3/1/2006 22:10:07.699
    Länge: 2:00.000
    5.760.000 samples


    Dateiname: 120secNoise.wav <----- URSPRUNG! (ohne angefügte Stille)
    Ordner: D:
    Dateityp: 48000 Hz, 16-Bit, Stereo
    Unkomprimierte Größe: 21.97 MB (23.040.000 bytes)
    Dateiformat: Windows PCM
    Windows PCM
    Größe auf Disk: 21.97 MB (23.040.044,00 bytes)
    Zuletzt gesp. (lokal): 3/1/2006 21:42:45.587
    Länge: 2:00.000
    5.760.000 samples

    --------------------------------------------------------------------------------

    katjarella
    Bitte nochmal testen, müsste jetzt stimmen.
    Wie gesagt, habe es mit 16bit, stereo und 480000hz getestet.

    Der Bug war wie angenommen, nach ReadWord() in der Datei ist der Filepointer 2 bytes hinter dem gefundenen 'start' wert, daher 2 vom gefundenen 'start' wert Ergebnis subtrahiert.
    Beim Finden des 'end' Wertes war ein ähnlicher Fehler drin, ebenso gefixed.

  • nein geht nicht. Er cuttet es schon richtig, aber per Hexeditor sieht man am Ende immer noch die überflüssigen byte 00 00 00 00 00 00 00 *****

    und somit ist jetzt:
    TotalSamples=144000 Duration=00:00:03.005
    Ziel ist TotalSamples=144000 Duration=00:00:03.000

    LigH warum bist Du schon wieder schneller? :D

    Edit noch was anderes längeres:

    MUTE2sec_TESTSIGNAL12sec_MUTE2sec.wav

    Code
    Bitrate=1536000Actual rate=1536000.000000Byte rate=192000Sampling Frec=48000Bits of Prec=16TotalSamples=768000Bytespersample=   4.0000Filesize=3072044Duration=00:00:16.000Channels mode=2 Channels

    TESTSIGNAL12sec_cuttet.wav

    Code
    Bitrate=1536000Actual rate=1536000.000000Byte rate=192000Sampling Frec=48000Bits of Prec=16TotalSamples=576000Bytespersample=   4.0000Filesize=2305068[COLOR='Red']Duration=00:00:12.005[/COLOR]Channels mode=2 Channels

    Richtig nach löschen der 00 00 * Bytes :

    Code
    Bitrate=1536000
    Actual rate=1536000.000000
    Byte rate=192000
    Sampling Frec=48000
    Bits of Prec=16
    TotalSamples=576000
    Bytespersample=   4.0000
    Filesize=2304044
    [COLOR='#4169e1']Duration=00:00:12.000[/COLOR]
    Channels mode=2 Channels
  • Ich /"&(/§&"(§("%§("§(-diot

    Code
    totalsize   = t_waveinfo\data_ckSizebufferrest  = t_waveinfo\data_ckSize % 1024 ; // Getting size of rest data which doesnt match 1MB buffer sizebuffercount = (t_waveinfo\data_ckSize-bufferrest) / 1024 ; // 1MB bufferBuffer = AllocateMemory(1024)PrintN("Copying trimmed PCM data ..."); // 1MB buffer based data copyFor i = 0 To buffercount     UseFile(#Source)    ReadData(Buffer, 1024)     UseFile(#Target)    WriteData(Buffer, 1024)Next i


    Naaaa wo liegt der Fehler??? ;)

    HIER:

    Code
    For i = 0 To buffercount      UseFile(#Source)     ReadData(Buffer, 1024)      UseFile(#Target)     WriteData(Buffer, 1024) Next i


    Demnach

    Code
    For i = 0 To buffercount -1  ; // <-----------
         UseFile(#Source)
         ReadData(Buffer, 1024) 
         UseFile(#Target)
         WriteData(Buffer, 1024)
     Next i


    und hoffentlich WARS das.
    (Die Änderungen in 0.12 waren dennoch nötig)

    Habe nun mit Vers. 0.13 das Ende genau gechecked und es sind die exact gleichen Werte nach der Wellenformanzeige via Audition. Die Wave-File-Endsizes sind ebenso gleich.


    Jetzt:

    ------------------------------------------------------
    Dateiname: Trimmed.wav (KillSilence's output)
    Ordner: D:
    Dateityp: 48000 Hz, 16-Bit, Stereo
    Unkomprimierte Größe: 21.97 MB (23.040.000 bytes)
    Dateiformat: Windows PCM
    Windows PCM
    Größe auf Disk: 21.97 MB (23.040.044,00 bytes) inklusive WeaveHeader
    Zuletzt gesp. (lokal): 3/1/2006 23:31:31.992
    Länge: 2:00.000
    5.760.000 samples


    Dateiname: 120secNoise.wav (original ohne angehangene Stille(n) )
    Ordner: D:
    Dateityp: 48000 Hz, 16-Bit, Stereo
    Unkomprimierte Größe: 21.97 MB (23.040.000 bytes)
    Dateiformat: Windows PCM
    Windows PCM
    Größe auf Disk: 21.97 MB (23.040.044,00 bytes) inklusive WeaveHeader
    Zuletzt gesp. (lokal): 3/1/2006 21:42:45.587
    Länge: 2:00.000
    5.760.000 samples

    ---------------------------------------------------

    Bitte bestätigen .... jetzt lecker??

  • Zitat

    und somit ist jetzt:
    TotalSamples=144000 Duration=00:00:03.005
    Ziel ist TotalSamples=144000 &nbsp;Duration=00:00:03.000

    Was für deinen Parser spricht, der von Audition liest die Duration aus den Daten des Waveheaders heraus, daher war da in der Waveformanzeige NIX von einer Flatline am Ende zu sehen. Dein genutzter nimmt die tatsächlichen phys. Bytes als Time-length. Was imho gerade bei solchen 'merge' workouts extrem verlässlicher ist.

    Übrigens:
    Eine sehr gute Seite:
    http://www-mmsp.ece.mcgill.ca/Documents/Audi…/WAVE/WAVE.html

  • Bei mir gibt's immer noch 2 Bytes zu viel...

    Ein WAV-Header kann vereinfacht sein (16 Bytes im "fmt "-Chunk, oder 44 Bytes gesamt) oder ausführlich, indem da noch drin steht "0 Bytes formatspezifische Daten" (dann sind's 18 Bytes im "fmt "-Chunk, bzw. 46 Bytes gesamt).

Jetzt mitmachen!

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