2010-07-03 45 views
7

Fondamentalmente, ho molti file audio che rappresentano la stessa canzone. Tuttavia, alcuni di questi sono di qualità peggiore rispetto all'originale e alcuni sono modificati in modo che non corrispondano più alla canzone originale. Quello che mi piacerebbe fare è confrontare a livello di codice questi file audio con l'originale e vedere quali corrispondono a quella canzone, indipendentemente dalla qualità. Un confronto diretto ovviamente non funzionerebbe perché la qualità dei file varia.Confronta due file audio

Credo che questo potrebbe essere fatto analizzando la struttura delle canzoni e confrontando con l'originale, ma non so nulla di ingegneria audio, quindi non mi aiuta molto. Tutte le canzoni sono dello stesso formato (MP3). Inoltre, sto usando Python, quindi se ci sono collegamenti per questo, sarebbe fantastico; in caso contrario, qualcosa per la JVM o anche una libreria nativa andrebbe bene, a patto che venga eseguito su Linux e io possa capire come usarlo.

+1

Guarda come funziona Shazam: http://laplacian.wordpress.com/2009/01/10/how-shazam-works/ –

+0

+1, post del blog fresco – BenG

+0

Hmm, sembra che questo non sia semplice come Pensavo che sarebbe stato. –

risposta

4

Copia da that risposta:

L'esatto stessa domanda che le persone al vecchio Audioscrobbler e attualmente a MusicBrainz hanno lavorato da molto tempo. Per il momento, il progetto Python che può aiutare nella tua ricerca, è Picard, che taggherà i file audio (non solo i file MPEG 1 Layer 3) con un GUID (in realtà, molti di loro), e da allora in poi, facendo corrispondere il i tag sono abbastanza semplici.

Se si preferisce farlo come un proprio progetto, libofa potrebbe essere di aiuto. Forse il documentation for the Python wrapper ti aiuterà di più.

+0

Ho finito per usare Picard, almeno per ora. Grazie. :) –

6

Prima di tutto, dovrai cambiare il tuo dominio di comparazione. L'analisi di campioni grezzi dai file non compressi non ti porterà da nessuna parte. La misura della distanza sarà basata su una o più funzionalità estratte dai campioni audio. Wikipedia elenca le seguenti caratteristiche come comunemente usati per Acoustic Fingerprinting:

caratteristiche percettive spesso sfruttati dalle impronte digitali audio includono tasso medio zero crossing, tempo stimato, spettro medio, piattezza spettrale, i toni di primo piano attraverso una serie di bande, e larghezza di banda.

non ho soluzioni programmatiche per voi, ma qui è un interesting attempt al reverse engineering del sistema di YouTube Audio ID. Viene utilizzato per il rilevamento delle violazioni del copyright, un problema simile.

13

Questo non è in realtà un compito banale. Non credo che una libreria pronta possa farlo. Ecco un possibile approccio:

  1. Decodifica da mp3 a PCM.
  2. Verificare che i dati PCM dispongano di una frequenza di campionamento specifica, scelta a priori (ad esempio 16 KHz). Dovrai ricampionare i brani con frequenza di campionamento diversa. Non è necessaria un'alta frequenza di campionamento poiché è comunque necessario un confronto sfocato, ma una frequenza di campionamento troppo bassa perderà troppi dettagli.
  3. Normalizza i dati PCM (ovvero trova il valore massimo del campione e ridimensiona tutti i campioni in modo che il campione con ampiezza più ampia utilizzi l'intero intervallo dinamico del formato dati, ad esempio se il formato del campione è firmato a 16 bit, quindi dopo la normalizzazione il campione di ampiezza massima dovrebbe avere il valore 32767 o -32767).
  4. Dividere i dati audio in frame di un numero fisso di campioni (ad esempio 1000 campioni per frame).
  5. Convertire ciascun frame nel dominio dello spettro (FFT).
  6. Calcola la correlazione tra le sequenze di frame che rappresentano due brani. Se la correzione è maggiore di una certa soglia, supponi che le canzoni siano le stesse.

librerie Python:

  • PyMedia (per il punto 1)
  • NumPy (per l'elaborazione dei dati) - vedi anche this article per alcune informazioni introduttive

Un'ulteriore complicazione. Le tue canzoni potrebbero avere un diverso periodo di silenzio all'inizio.Per evitare falsi negativi, potrebbe essere necessario un ulteriore passaggio:

3.1. Scansiona i dati PCM dall'inizio, fino a quando l'energia sonora supera la soglia predefinita. (Ad esempio, calcolare RMS con una finestra scorrevole di 10 campioni e fermarsi quando supera l'1% della gamma dinamica). Quindi scartare tutti i dati fino a questo punto.

+0

I dati PCM sono un array di byte giusto? Nel passaggio 3, mentre normalizziamo poiché abbiamo bisogno di ampiezze fino a 32767, credo che lo convertireste in un intero/doppio array. Per favore correggimi se sbaglio. Inoltre, dobbiamo calcolare la correlazione nel passaggio 6? O cosa succede se confrontiamo semplicemente i valori di fft e vediamo se rientrano in una soglia? – LINGS

+0

@LINGS (3) presuppone che i dati PCM del passaggio (1) siano un array di tipo appropriato (ad esempio int16 o float32). Ma se il decodificatore di scelta restituisce byte non elaborati allora sì, è necessario un passaggio di conversione. – atzz

+0

@LINGS re step (6): la semplice differenza non funziona se la soluzione deve tollerare il rumore, perché alcuni disturbi come i clic o le applausi causano una grande differenza in FFT. La differenza integrata potrebbe funzionare comunque. Non sono sicuro che la correlazione sia il miglior metodo di confronto qui, non l'ho ricercato come probabilmente avrei dovuto, ma ha funzionato bene quando ho implementato qualcosa di simile. – atzz