[C] File audio WAV: devo leggerne l'Header x saperne la lunghezza in tempo?!

[andbin]

Ecco il sorgente per una applicazione "console" che ho appena scritto per visualizzare numero di campioni, frequenza di campionamento e durata di un file WAV in formato PCM.

Naturalmente il sorgente non ha la pretesa di essere perfetto al 100%. In ogni caso può essere un ottimo punto di partenza!

Compilato con VC++.net 2003 e testato sui diversi file WAV forniti con Windows (per verificare, ho aperto i file anche con il "registratore di suoni" di Windows che mostra la durata).

#define STRICT
#include <windows.h>
#include <stdio.h>

#define WAVINFO_SUCCESS     0       /* Successo */
#define WAVINFO_IOERROR     1       /* Errore di I/O */
#define WAVINFO_BADFMT      2       /* Formato file non adatto */

#define WAVEFMT_SIZE        (sizeof (WAVEFORMATEX) - 2)

INT ReadWavInfo (LPSTR lpszFilename, LPDWORD lpdwSamples, LPDWORD lpdwFrequency)
{
    HMMIO           hmmio;
    MMCKINFO        mmckinfoWave;
    MMCKINFO        mmckinfoFmt;
    MMCKINFO        mmckinfoData;
    WAVEFORMATEX    wavefmt;

    hmmio = mmioOpen (lpszFilename, NULL, MMIO_READ);

    if (hmmio == NULL)
        return WAVINFO_IOERROR;

    mmckinfoWave.fccType = mmioFOURCC ('W', 'A', 'V', 'E');

    if (mmioDescend (hmmio, &mmckinfoWave, NULL, MMIO_FINDRIFF) != MMSYSERR_NOERROR)
    {
        mmioClose (hmmio, 0);
        return WAVINFO_IOERROR;
    }

    mmckinfoFmt.ckid = mmioFOURCC ('f', 'm', 't', ' ');

    if (mmioDescend (hmmio, &mmckinfoFmt, &mmckinfoWave, MMIO_FINDCHUNK) != MMSYSERR_NOERROR)
    {
        mmioClose (hmmio, 0);
        return WAVINFO_IOERROR;
    }

    if (mmckinfoFmt.cksize < WAVEFMT_SIZE)
    {
        mmioClose (hmmio, 0);
        return WAVINFO_BADFMT;
    }

    if (mmioRead (hmmio, (HPSTR) &wavefmt, WAVEFMT_SIZE) != WAVEFMT_SIZE)
    {
        mmioClose (hmmio, 0);
        return WAVINFO_IOERROR;
    }

    if (wavefmt.wFormatTag != WAVE_FORMAT_PCM)
    {
        mmioClose (hmmio, 0);
        return WAVINFO_BADFMT;
    }

    if (mmioAscend (hmmio, &mmckinfoFmt, 0) != MMSYSERR_NOERROR)
    {
        mmioClose (hmmio, 0);
        return WAVINFO_IOERROR;
    }

    mmckinfoData.ckid = mmioFOURCC ('d', 'a', 't', 'a');

    if (mmioDescend (hmmio, &mmckinfoData, &mmckinfoWave, MMIO_FINDCHUNK) != MMSYSERR_NOERROR)
    {
        mmioClose (hmmio, 0);
        return WAVINFO_IOERROR;
    }

    *lpdwSamples = mmckinfoData.cksize / (wavefmt.nChannels * (wavefmt.wBitsPerSample / 8));
    *lpdwFrequency = wavefmt.nSamplesPerSec;

    mmioClose (hmmio, 0);

    return WAVINFO_SUCCESS;
}


int main (int argc, char *argv[])
{
    INT     iRet;
    DWORD   dwSamples, dwFrequency;

    if (argc == 2)
    {
        iRet = ReadWavInfo (argv[1], &dwSamples, &dwFrequency);

        switch (iRet)
        {
            case WAVINFO_SUCCESS:
                printf ("Numero campioni         = %lu\n", dwSamples);
                printf ("Frequenza campionamento = %lu Hz\n", dwFrequency);
                printf ("Durata                  = %.3f secondi\n", ((double) dwSamples) / dwFrequency);
                break;
            case WAVINFO_IOERROR:
                printf ("Errore di I/O\n");
                break;
            case WAVINFO_BADFMT:
                printf ("Formato del file non adatto\n");
                break;
        }
    }

    return 0;
}

EDIT: ho nuovamente apportato qualche miglioramento.

[Matrixbob]

Grazie vado a cercare d'elaborare una soluzione al mio problema.

[Matrixbob]

OK, problemi in compilazione.

Errore 1]
Che ho risolto in seguito:



, linkando nelle proprietà del compilatore di CodeBlocks, il file: "libwinmm.a".
L'ho fatto in CodeBlocks perchè col GCC non mi ricordo + come si linka.

Errore 2]
Che non sono ancora riuscito ad evitare:



CPU_FEATURES_INIT
, usando CodeBlocks sul codice sia di Andbin, sia di Okay, che del WevParser d'esempio HMMIO esce quel errore.

Magari quando capisco come linkare in GCC, provo a vedere se è 1 errore relativo a CodeBlocks

[Matrixbob]

ADESSO LE COMPILAZIONI VANNO A BUON FINE, MA...

... al momento di leggere 1 file creato con lo strumento di Text To Speech (TTS) "DSpeech" di Dimitrios, il programmino di Andbin, mi dice che è mal formato, e questo è strano perchè Dimio mi ha detto di aver usato le API di Windows x il suo lavoro.



Quello di Okay va a segno:



Anche il codice dimostrativo di HMMIO:



Queste sono le impostazioni di DSpeech:

[andbin]

Originariamente inviato da Matrixbob

... al momento di leggere 1 file creato con lo strumento di Text To Speech (TTS) "DSpeech" di Dimitrios, il programmino di Andbin, mi dice che è mal formato, e questo è strano perchè Dimio mi ha detto di aver usato le API di Windows x il suo lavoro.

Il problema non è il file .wav, ma il mio sorgente. Inizialmente avevo fatto un controllo troppo rigoroso sulla dimensione del chunk "fmt". Leggendo meglio della documentazione sul formato WAV che ho trovato in rete, ho riscontrato che il contenuto di questo chunk può anche essere più lungo dei 16 byte "tipici".

Ho corretto/migliorato e quindi ripostato il sorgente nel mio post #41. Come avevo ben detto, non avevo alcuna pretesa che fosse perfetto al 100%.

[Matrixbob]

Andbin, come mai al inizio del tuo sorgente non trovo l'include delle include <mmsystem.h>?

#define STRICT
#include <windows.h>
#include <stdio.h>

Perchè la includo io col -lwinmm in compilazione?!
Fare l'include o l'opz -lwinmm è la stessa cosa?!

Invece questa

#define STRICT

a che serve?
Io le DEFINE sono abituato a vederle associare delle costanti a dei nomi.

[andbin]

Originariamente inviato da Matrixbob

Andbin, come mai al inizio del tuo sorgente non trovo l'include delle include <mmsystem.h>?

Perché la documentazione su MSDN per le varie funzioni mmioXXX dice:
Header: Declared in Mmsystem.h; include Windows.h.

Cioè sono effettivamente dichiarate in Mmsystem.h ma è sufficiente includere Windows.h

Originariamente inviato da Matrixbob

#define STRICT
a che serve?
Io le DEFINE sono abituato a vederle associare delle costanti a dei nomi.

La macro STRICT serve per fare in modo che negli header del PSDK certi tipi di dati (principalmente gli handle ma anche altri) vengano definiti in modo che siano distinti e non assegnabili tra di loro (senza un cast esplicito).

Comunque leggi <qui> che spiega bene la cosa.

[Matrixbob]

Ok, TNX.

Altra cosa che ho notato è che usi dei tipi
INT e int, c'è differenza?

[andbin]

Originariamente inviato da Matrixbob

Altra cosa che ho notato è che usi dei tipi
INT e int, c'è differenza?

Negli header del PSDK vengono definiti molti tipi di dati, come INT, DWORD, LPBYTE, ecc....
Poi se vai a vedere in WinDef.h, INT è un semplice typedef per int, BYTE è un typedef per unsigned char, ecc...
Quando si programma a livello Win32 in genere è preferibile usare i suoi tipi di dati.

[Matrixbob]

Originariamente inviato da andbin

Negli header del PSDK vengono definiti molti tipi di dati, come INT, DWORD, LPBYTE, ecc....
Poi se vai a vedere in WinDef.h, INT è un semplice typedef per int, BYTE è un typedef per unsigned char, ecc...
Quando si programma a livello Win32 in genere è preferibile usare i suoi tipi di dati.

Ok ho imparato anche questo che mi suonava nuovo.
CMQ vedere 1 define prima degli include fa effetto.

[Matrixbob]

Per chi è rimasto sottoscritto a questo 3D segnalo il suo gemello:
[C] File audio MP3: devo leggerne l'Header x saperne la lunghezza in tempo?!