Autenticità audio: tagli, montaggi e ricodifiche

Introduzione

Una registrazione audio può essere prodotta da:

• smartphone;
• registratore digitale;
• computer;
• sistema di videosorveglianza;
• centralino telefonico;
• piattaforma di videoconferenza;
• applicazione di messaggistica;
• sistema VoIP;
• telecamera;
• dispositivo indossabile;
• registratore professionale;
• software di editing.

La stessa registrazione può successivamente essere:

• inoltrata;
• estratta da una chat;
• convertita;
• ricodificata;
• compressa;
• normalizzata;
• filtrata;
• tagliata;
• concatenata;
• registrata nuovamente attraverso un altoparlante;
• inserita in un video;
• esportata da un’applicazione;
• sincronizzata nel cloud.

Quando un cliente di Roma consegna un file audio e chiede:

la domanda deve essere precisata.

“Originale” può significare:

1. prima registrazione prodotta dal dispositivo;
2. prima copia trasferibile del file;
3. file estratto direttamente dall’applicazione;
4. file non modificato dopo la registrazione;
5. file contenente una conversazione continua;
6. file coerente con il dispositivo dichiarato;
7. file non generato o alterato mediante intelligenza artificiale;
8. contenuto corrispondente a quanto realmente accaduto.

Questi significati non coincidono.

Un file può essere tecnicamente compatibile con una registrazione continua, ma rappresentare una conversazione preparata o recitata.

Un file può essere una copia ricodificata di una registrazione genuina.

Un messaggio vocale può essere stato inoltrato senza alterazioni sostanziali del parlato, ma non essere più identico al file creato dal dispositivo sorgente.

Una registrazione può contenere una pausa prodotta dalla funzione nativa dell’applicazione e non da un montaggio successivo.

L’analisi deve quindi verificare se le caratteristiche osservate siano coerenti con la storia dichiarata del reperto.

Le buone pratiche ENFSI descrivono l’autenticità audio come una valutazione della compatibilità tra le tracce presenti nella registrazione, il processo dichiarato di acquisizione e l’eventuale presenza di elementi non spiegabili mediante tale processo. Il metodo non dovrebbe ridursi a una risposta automatica “autentico” o “falso”, ma valutare ipotesi alternative e la forza con cui le osservazioni le sostengono. Consulta i Best Practice Manual ENFSI.

Anche SWGDE sottolinea che non esiste un procedimento universale capace di dichiarare autentico qualsiasi file senza conoscere:

• il dispositivo;
• il formato;
• le modalità di registrazione;
• le modifiche contestate;
• la provenienza;
• il contesto.

Consulta le best practice SWGDE per l’autenticazione audio digitale.

Sintesi operativa

1. acquisire il file nella forma più vicina possibile all’originale;
2. chiedere il dispositivo e l’applicazione che avrebbero prodotto la registrazione;
3. documentare ogni passaggio di inoltro, export o conversione;
4. calcolare l’hash prima di aprire o elaborare il file;
5. identificare formato, contenitore, codec e stream reali;
6. acquisire metadati, struttura, pacchetti e informazioni del codec;
7. conservare separatamente originale e copie di analisi;
8. decodificare una copia in PCM senza normalizzazione o filtri;
9. effettuare ascolto controllato e annotare i punti contestati;
10. analizzare waveform e spettrogramma con parametri documentati;
11. verificare rumore, riverbero, fase, DC offset e continuità;
12. esaminare frame, pacchetti, bitrate e possibili doppie codifiche;
13. cercare tagli, crossfade, concatenazioni e intervalli replicati;
14. valutare AGC, noise suppression, codec e piattaforme di trasmissione;
15. acquisire eventuali registrazioni di riferimento;
16. confrontare il file con il dispositivo e il workflow dichiarato;
17. correlare chat, email, video, cloud, log e file sorgenti;
18. evitare di confondere ricodifica, montaggio e falsità del contenuto;
19. descrivere sempre ipotesi alternative e limiti;
20. produrre output tecnici, timeline e relazione riproducibile.

1. Avvertenza preliminare

Le procedure descritte devono essere utilizzate esclusivamente:

• su registrazioni proprie;
• su file consegnati dal legittimo titolare;
• nell’ambito di un incarico professionale;
• in attività difensive o aziendali autorizzate;
• su copie di lavoro;
• nel rispetto della riservatezza;
• con un quesito tecnico chiaramente definito.

Non è lecito utilizzare queste procedure per:

• intercettare comunicazioni;
• accedere a dispositivi di terzi;
• utilizzare password o token non autorizzati;
• acquisire microfono o chiamate da remoto;
• installare software di registrazione occulto;
• entrare in account personali;
• modificare il reperto originale;
• diffondere conversazioni private;
• pubblicare registrazioni allo scopo di danneggiare qualcuno.

La liceità della registrazione, della sua diffusione e della sua produzione in giudizio deve essere valutata dall’avvocato.

L’articolo 617-septies del codice penale riguarda, nei presupposti previsti dalla norma, la diffusione fraudolenta di riprese o registrazioni di incontri e conversazioni private con finalità lesive della reputazione o dell’immagine. La disposizione contempla specifiche esclusioni per l’utilizzazione diretta in procedimenti, per l’esercizio del diritto di difesa e per il diritto di cronaca. Testo normativo su Gazzetta Ufficiale.

Il perito deve evitare di:

• duplicare inutilmente il file;
• inserirlo integralmente in allegati non riservati;
• diffondere voci o dati personali non pertinenti;
• consegnare versioni migliorate senza indicarne la natura derivata;
• formulare conclusioni giuridiche.

2. Inquadramento probatorio essenziale

L’articolo 2712 del codice civile include le registrazioni fonografiche e le riproduzioni informatiche tra le rappresentazioni meccaniche di fatti e cose, disciplinandone l’efficacia in relazione all’eventuale disconoscimento della conformità. La valutazione processuale concreta spetta al legale e al giudice. Testo dell’articolo 2712.

Dal punto di vista tecnico, un eventuale disconoscimento può rendere particolarmente rilevanti:

• provenienza del file;
• catena di custodia;
• dispositivo sorgente;
• continuità;
• struttura;
• metadati;
• codec;
• eventuali ricodifiche;
• punti di sospetta alterazione;
• versioni alternative;
• contesto della conversazione.

Le regole deontologiche italiane per i trattamenti svolti nell’ambito di investigazioni difensive o per far valere un diritto si applicano anche ai professionisti che trattano dati su incarico per tali finalità. Regole deontologiche del Garante.

La relazione informatica dovrebbe quindi distinguere:

accertamento tecnico
≠
ammissibilità processuale
≠
valore probatorio
≠
liceità della registrazione
≠
responsabilità personale

3. Che cosa significa autenticità audio

Un file può essere considerato tecnicamente compatibile con la storia dichiarata quando:

• la struttura è coerente con il dispositivo o software indicato;
• i parametri di registrazione sono coerenti;
• non emergono discontinuità non spiegate;
• non sono rilevate tracce di post-produzione incompatibili;
• i metadati non presentano conflitti sostanziali;
• il segnale mantiene caratteristiche coerenti;
• gli elementi esterni supportano la provenienza.

Le linee guida ENFSI considerano autentica, in senso tecnico, una registrazione continua, prodotta contemporaneamente agli eventi acustici dichiarati, coerente con il metodo di registrazione e priva di artefatti o discontinuità non spiegabili. La valutazione deve però essere formulata in termini di sostegno relativo alle ipotesi, non come certificazione assoluta. Best Practice Manual ENFSI per l’autenticità audio.

3.1 Registrazione continua

Una registrazione continua è stata acquisita senza interruzioni nella sequenza temporale rappresentata.

Non significa necessariamente che:

• non vi siano silenzi;
• il soggetto non abbia smesso di parlare;
• il microfono non sia stato mosso;
• il software non abbia applicato AGC;
• la registrazione non sia stata compressa.

3.2 Registrazione discontinua ma coerente

Una registrazione può contenere:

• pausa nativa;
• arresto e ripresa;
• segmenti prodotti dall’app;
• interruzione causata da una chiamata;
• cambio automatico di file.

Può essere tecnicamente coerente con il dispositivo, ma non deve essere descritta come registrazione continua.

3.3 File derivato

Un file derivato può essere:

• un export;
• una copia;
• un allegato estratto;
• una ricodifica;
• un audio estratto da un video;
• una registrazione dello schermo.

Il contenuto può essere utile, ma il file non è più necessariamente l’originale tecnico.

4. Autenticità tecnica e verità del contenuto

L’analisi di autenticità non determina automaticamente se:

• le parole pronunciate siano vere;
• la conversazione sia spontanea;
• i partecipanti sapessero della registrazione;
• il contesto rappresentato sia completo;
• una persona abbia mentito;
• la scena sia stata preparata;
• il file sia stato ottenuto lecitamente.

Esempio:

Il file può essere una registrazione continua e non modificata
di una conversazione recitata o preparata.

La formula corretta è:

Non:

5. Autenticità, intelligibilità e identificazione vocale

Sono attività differenti.

5.1 Autenticità

Verifica la compatibilità del file con il processo dichiarato.

5.2 Intelligibilità

Cerca di rendere più comprensibile il parlato attraverso:

• riduzione del rumore;
• equalizzazione;
• selezione di canale;
• regolazione del livello.

5.3 Identificazione o confronto vocale

Valuta la compatibilità tra:

• voce ignota;
• voce di riferimento.

Richiede metodologia e competenze specifiche e non deve essere sostituita da un’impressione soggettiva del tipo:

5.4 Rilevazione di voce sintetica

Riguarda:

• voice cloning;
• text-to-speech;
• conversione vocale;
• audio generato.

Sarà trattata nel Capitolo 25 — Voice cloning e audio generati con intelligenza artificiale.

6. Metodi informati e metodi blind

Le buone pratiche ENFSI distinguono due grandi classi.

6.1 Analisi informata

Confronta il reperto con informazioni note:

• dispositivo;
• app;
• firmware;
• impostazioni;
• luogo;
• ora;
• eventi dichiarati;
• registrazioni di riferimento.

6.2 Analisi blind

Esamina il file senza dipendere da una ricostruzione fornita dal cliente.

Può cercare:

• discontinuità;
• doppia codifica;
• intervalli replicati;
• cambi di rumore;
• cambi di riverbero;
• alterazioni della struttura;
• variazioni di quantizzazione;
• frame anomali.

Entrambi gli approcci sono utili. L’analisi informata può spiegare anomalie apparentemente sospette; quella blind può individuare elementi non dichiarati. ENFSI Digital Audio Authenticity Analysis.

7. Tracce di registrazione e tracce di post-produzione

Durante l’acquisizione vengono introdotte tracce riconducibili a:

evento acustico
→ ambiente
→ microfono
→ elettronica
→ convertitore A/D
→ codec
→ contenitore
→ memoria

Possono emergere:

• risposta del microfono;
• rumore termico;
• riverbero;
• rumore ambientale;
• DC offset;
• sample rate;
• bit depth;
• artefatti del codec;
• struttura del file;
• metadati.

Operazioni successive possono introdurre:

• dipendenze da ricampionamento;
• doppia codifica;
• nuovi cutoff;
• variazioni di quantizzazione;
• segmenti replicati;
• discontinuità;
• crossfade;
• metadati di software;
• nuova struttura del contenitore.

Le linee guida ENFSI includono tra i possibili indicatori di post-produzione le dipendenze tra campioni introdotte dal resampling, le tracce di doppia codifica e gli intervalli replicati. Approfondimento ENFSI.

8. Che cosa può chiedere un cliente

Un avvocato di Roma può chiedere:

• la conversazione è continua?
• esistono tagli?
• sono state unite due registrazioni?
• il silenzio è naturale?
• il messaggio è stato ricodificato?
• il file proviene da WhatsApp?
• la registrazione è compatibile con un iPhone?
• è stata registrata da un altoparlante?
• l’audio è stato estratto da un video?
• esistono tracce di editing?
• il file contiene una pausa nativa?
• è possibile stabilire data e ora?
• è la stessa registrazione presente in un’altra chat?
• la voce è generata artificialmente?

La risposta dipende dal materiale disponibile.

9. Che cosa non deve promettere il perito

Non promettere:

• autenticità certa;
• individuazione di ogni taglio;
• identificazione automatica dell’autore;
• recupero di parti eliminate;
• datazione assoluta;
• ricostruzione di parole non più presenti;
• esclusione totale di manipolazioni;
• riconoscimento certo della voce;
• rilevazione infallibile dell’intelligenza artificiale.

Una manipolazione ben realizzata può non lasciare tracce rilevabili nel file disponibile.

Una ricodifica può cancellare o mascherare indicatori precedenti.

Un file di bassa qualità può non contenere informazioni sufficienti.

10. Materiale da richiedere

[ ] file più vicino all’originale;
[ ] dispositivo sorgente;
[ ] applicazione utilizzata;
[ ] versione dell’app;
[ ] sistema operativo;
[ ] registrazione nella chat originale;
[ ] email o cloud di provenienza;
[ ] file inoltrato;
[ ] eventuale video associato;
[ ] versioni alternative;
[ ] registrazioni precedenti e successive;
[ ] file di riferimento dello stesso dispositivo;
[ ] screenshot del contesto;
[ ] esportazione della conversazione;
[ ] informazioni sull’ora e sul luogo;
[ ] descrizione dei punti contestati.

Quando il file proviene da WhatsApp, Telegram o Signal, è preferibile acquisire anche:

• database;
• record del messaggio;
• allegato locale;
• identificativi;
• timestamp;
• dispositivo;
• backup.

11. Il file “più vicino all’originale”

La gerarchia orientativa è:

1. file nel dispositivo che ha registrato;
2. file estratto dal database o dall’app sorgente;
3. file conservato nel cloud originario;
4. allegato ricevuto nella forma nativa;
5. export dell’app;
6. file inoltrato;
7. file ricodificato;
8. registrazione dello schermo;
9. registrazione da altoparlante.

La gerarchia non è assoluta.

Un file estratto correttamente dal cloud può essere più affidabile di una copia locale modificata.

SWGDE raccomanda di privilegiare l’originale o la versione di qualità più elevata e di documentare le limitazioni quando è disponibile soltanto una copia derivata. Best Practices for Forensic Audio.

12. Questionario sulla provenienza

1. Chi ha effettuato la registrazione?
2. Con quale dispositivo?
3. Con quale applicazione?
4. Il telefono era in chiamata?
5. Il microfono era integrato o esterno?
6. La registrazione è stata messa in pausa?
7. Il telefono ha ricevuto chiamate o notifiche?
8. Il dispositivo è stato spostato?
9. La persona è passata in un altro ambiente?
10. Il file è stato inviato mediante chat?
11. È stato modificato per renderlo più chiaro?
12. È stato estratto da un video?
13. È stato convertito in MP3?
14. È stato caricato su un sito?
15. Esistono altre versioni?
16. In quale punto si sospetta il taglio?
17. Quale fatto dovrebbe essere dimostrato?

ENFSI raccomanda di raccogliere informazioni su contesto, attrezzatura, software, funzioni automatiche, interruzioni, microfono, data, trasferimenti e trattamenti applicati, poiché tali elementi possono spiegare apparenti anomalie. Manuale ENFSI.

13. Definire il quesito tecnico

Quesito improprio:

Quesiti più corretti:

- verificare se il file presenta discontinuità non spiegate;
- verificare se esistono tracce compatibili con un montaggio;
- stabilire se il file è stato ricodificato;
- confrontare la struttura con quella prodotta dal dispositivo;
- verificare se la pausa è compatibile con la funzione nativa;
- confrontare due versioni della registrazione;
- determinare se due file contengono lo stesso audio;
- documentare le limitazioni introdotte dalla messaggistica;
- verificare la compatibilità con una registrazione da altoparlante.

Formula:

14. Cartella del caso

CASO_RM_2026_024/
├── 00_incarico/
├── 01_verbali/
├── 02_originali/
├── 03_hash/
├── 04_copie_analisi/
├── 05_metadata/
├── 06_ffprobe/
├── 07_mediainfo/
├── 08_exiftool/
├── 09_packet_analysis/
├── 10_waveform/
├── 11_spectrogram/
├── 12_audio_stats/
├── 13_segmenti/
├── 14_reference_recordings/
├── 15_confronti/
├── 16_trascrizioni/
├── 17_timeline/
├── 18_immagini_report/
├── 19_report/
└── 20_relazione/

15. Registro dei reperti

16. Catena di custodia

Per ogni reperto registrare:

- identificativo;
- nome originale;
- fonte;
- dispositivo;
- applicazione;
- dimensione;
- data e ora;
- fuso;
- soggetto consegnante;
- modalità di trasferimento;
- hash;
- posizione di conservazione;
- copie;
- accessi;
- strumenti utilizzati.

La procedura generale è descritta nel Capitolo 2 — Catena di custodia, hash e verbale tecnico.

17. Calcolo dell’hash

Windows PowerShell

Get-FileHash -Algorithm SHA256 `
  -LiteralPath ".\registrazione.m4a"

Linux

sha256sum -- registrazione.m4a

macOS

shasum -a 256 -- registrazione.m4a

Registrare:

Nome:
Dimensione:
SHA-256:
Data:
Operatore:
Strumento:

L’hash del file completo comprende:

• audio;
• contenitore;
• metadati;
• padding;
• eventuali immagini;
• dati accessori.

Due file con audio percepibilmente uguale possono avere hash differenti.

18. Tre tipi di hash da distinguere

18.1 Hash binario del file

Identifica l’intero file bit per bit.

18.2 Hash dei pacchetti codificati

Può identificare i payload audio all’interno del contenitore.

18.3 Hash dell’audio decodificato

Può confrontare i campioni prodotti dal decoder secondo parametri uniformi.

FFmpeg supporta output hash, framehash e framemd5; il formato framehash produce un hash per ogni frame decodificato e utilizza SHA-256 come algoritmo predefinito. La conversione di default deve essere considerata nella comparazione e, per confronti controllati, è preferibile specificare esplicitamente il formato PCM. Documentazione FFmpeg sui formati hash.

19. Identificare il formato reale

Non fidarsi dell’estensione.

Un file chiamato:

vocale.mp3

può essere:

• MP3;
• AAC in contenitore MP4;
• Opus in Ogg;
• WAV rinominato;
• video con sola traccia audio;
• file non valido.

Linux e macOS

file --brief -- registrazione.mp3
file --brief --mime-type -- registrazione.mp3
xxd -l 128 -- registrazione.mp3

PowerShell

Format-Hex `
  -LiteralPath ".\registrazione.mp3" `
  -Count 128

20. Contenitore, codec ed estensione

Contenitore

Organizza:

• stream;
• metadati;
• timestamp;
• indice;
• capitoli;
• allegati.

Esempi:

• RIFF/WAV;
• MP4/M4A;
• Ogg;
• ASF;
• Matroska;
• 3GP.

Codec

Definisce come il segnale è codificato.

Esempi:

• PCM;
• MP3;
• AAC;
• Opus;
• Vorbis;
• FLAC;
• AMR;
• WMA.

Estensione

È il suffisso del nome:

.wav
.mp3
.m4a
.ogg
.opus
.amr

Non identifica con certezza né il contenitore né il codec.

21. Fondamenti dell’audio digitale

Un segnale digitale è rappresentato da campioni numerici.

Le principali proprietà sono:

• sample rate;
• bit depth o sample format;
• numero di canali;
• durata;
• codec;
• bitrate;
• modalità CBR o VBR;
• channel layout.

21.1 Sample rate

Indica quanti campioni sono rappresentati ogni secondo.

Esempi:

8.000 Hz
16.000 Hz
44.100 Hz
48.000 Hz
96.000 Hz

Il limite teorico delle frequenze rappresentabili è inferiore alla metà del sample rate.

Una registrazione a 8 kHz non contiene normalmente frequenze utili oltre circa 4 kHz.

21.2 Bit depth

Nei file PCM può indicare il numero di bit utilizzati per rappresentare ogni campione.

Nei codec lossy il concetto non coincide con il normale bit depth PCM.

21.3 Canali

Il file può essere:

• mono;
• stereo;
• dual mono;
• multicanale.

Due canali identici non costituiscono vero stereo.

22. Compressione lossless e lossy

22.1 Non compresso

Esempi:

• PCM in WAV;
• PCM in AIFF.

22.2 Lossless

Esempi:

• FLAC;
• ALAC.

La decodifica ricostruisce i campioni rappresentati dal file.

22.3 Lossy

Esempi:

• MP3;
• AAC;
• Opus;
• Vorbis;
• AMR;
• WMA lossy.

Il codec elimina o approssima informazioni secondo un modello di compressione.

Una successiva ricodifica lossy può introdurre ulteriori artefatti. Audacity avverte che importare un MP3, modificarlo ed esportarlo nuovamente come MP3 comporta una seconda perdita dovuta alla ricodifica. Opzioni di export MP3 di Audacity.

23. Formati comuni

24. WAV, RIFF e BWF

Un WAV è normalmente organizzato in chunk.

Possibili chunk:

RIFF
WAVE
fmt
data
LIST
bext
iXML
JUNK
ID3
C2PA

Non tutti i WAV contengono PCM.

Possono contenere:

• ADPCM;
• GSM;
• floating point;
• altri codec.

BWF MetaEdit supporta la lettura, validazione ed esportazione dei metadati Broadcast Wave e può gestire WAV e RF64; eventuali funzioni di scrittura devono essere utilizzate esclusivamente su copie. BWF MetaEdit.

24.1 Elementi da verificare

• coerenza delle dimensioni dei chunk;
• ordine;
• dati dopo il chunk audio;
• sample rate;
• bit depth;
• numero canali;
• durata calcolata;
• metadati BEXT;
• time reference;
• coding history;
• software.

24.2 Limite

Un WAV non è automaticamente originale o non modificato.

Qualsiasi editor può produrre un nuovo WAV.

25. MP3

Un MP3 è organizzato in frame audio e può contenere:

• ID3v2 iniziale;
• frame MPEG Audio;
• header VBR;
• padding;
• ID3v1 finale;
• metadati dell’encoder.

Possibili elementi:

• bitrate;
• CBR o VBR;
• sample rate;
• channel mode;
• encoder;
• delay;
• padding;
• cutoff;
• frame non coerenti;
• tag.

25.1 Attenzione

• un file MP3 può essere tagliato su confini di frame;
• alcuni strumenti possono eseguire operazioni senza ricodificare tutto;
• altri ricodificano l’intero contenuto;
• la doppia codifica può essere rilevabile, ma non sempre;
• un encoder diverso non dimostra manipolazione fraudolenta.

26. AAC, M4A e MP4

M4A è normalmente un contenitore ISO Base Media File Format con audio AAC o ALAC.

Può contenere:

• ftyp;
• moov;
• mdat;
• informazioni di traccia;
• timescale;
• duration;
• metadata atoms;
• encoder;
• gapless information.

26.1 Possibili criticità

• durata del contenitore differente dalla durata decodificata;
• edit list;
• padding;
• priming;
• file frammentato;
• ricodifica;
• metadata riscritti;
• estrazione da video.

Non interpretare automaticamente un piccolo scarto temporale come taglio.

27. Ogg, Opus e Vorbis

Ogg è un contenitore a pagine.

Può contenere stream:

• Opus;
• Vorbis;
• altri.

Elementi utili:

• serial number logico;
• page sequence;
• granule position;
• checksum;
• header del codec;
• commenti;
• durata;
• eventuali concatenazioni.

27.1 Messaggi vocali

Messaggi vocali provenienti da applicazioni possono essere frequentemente codificati in Opus e racchiusi in Ogg, ma formato e comportamento devono essere verificati caso per caso.

Non attribuire l’applicazione dalla sola estensione.

28. AMR e telefonia

AMR può essere:

• narrowband;
• wideband;
• contenuto in file dedicato;
• contenuto in 3GP;
• utilizzato nei sistemi telefonici.

La qualità limitata può derivare da:

• banda telefonica;
• codec;
• perdita di pacchetti;
• noise suppression;
• comfort noise;
• echo cancellation;
• transcodifica.

Discontinuità o suoni metallici possono essere prodotti dal sistema di trasmissione e non da un montaggio.

29. FLAC e ALAC

FLAC e ALAC sono codec lossless.

La ricodifica da PCM a FLAC e ritorno può mantenere i campioni audio, ma modificare:

• contenitore;
• metadati;
• padding;
• identificativi;
• hash del file.

Un FLAC derivato da MP3 resta limitato dalla precedente compressione lossy.

La sola conversione in un formato lossless non ripristina le informazioni eliminate dal codec precedente.

30. Audio contenuto in un video

Un video può includere:

• più tracce audio;
• audio principale;
• commento;
• microfoni separati;
• timecode;
• offset;
• edit list;
• audio ricodificato.

L’analisi deve preservare il file video completo.

Il flusso audio può essere estratto senza ricodifica e analizzato separatamente, ma la sincronizzazione con i frame video deve essere mantenuta.

Vedere:

• Autenticità video: frame, codec, tagli e montaggi
• Analisi video deepfake e face swapping

31. Messaggi vocali di messaggistica

Un vocale può essere:

• registrato nell’app;
• importato come allegato;
• inoltrato;
• scaricato;
• esportato;
• registrato nuovamente.

31.1 Acquisire

- file allegato;
- record del messaggio;
- timestamp;
- mittente;
- destinatario;
- ID;
- database;
- versione dell’app;
- dispositivo;
- eventuale originale esterno.

31.2 Inoltro

L’inoltro può:

• mantenere il payload;
• creare un nuovo oggetto;
• modificare metadati;
• ricodificare;
• rinominare;
• perdere informazioni.

Il comportamento deve essere verificato sulla specifica versione dell’app e, quando possibile, mediante registrazioni di riferimento.

32. Registrazioni telefoniche e VoIP

I sistemi telefonici possono applicare:

• voice activity detection;
• silence suppression;
• comfort noise;
• automatic gain control;
• echo cancellation;
• packet loss concealment;
• jitter buffer;
• transcodifica;
• separazione dei canali;
• registrazione lato server.

32.1 Conseguenze

Possono comparire:

• silenzi artificiali;
• brusche variazioni di rumore;
• parole parziali;
• ripetizioni;
• suoni metallici;
• ritardi;
• differenze tra canali.

Questi fenomeni non devono essere scambiati automaticamente per montaggi.

33. Registrazioni da smartphone

Uno smartphone può applicare automaticamente:

• riduzione del rumore;
• beamforming;
• AGC;
• high-pass filter;
• compressione dinamica;
• cancellazione del vento;
• cambio microfono;
• pause;
• segmentazione.

33.1 Acquisizione Android

Vedere il Capitolo 6 — Acquisizione forense di smartphone Android.

33.2 Acquisizione iPhone

Vedere il Capitolo 7 — Acquisizione forense di iPhone e iPad iOS.

34. Metadati audio

Possibili metadati:

• titolo;
• artista;
• data;
• encoder;
• software;
• modello;
• commento;
• time reference;
• geolocalizzazione;
• numero traccia;
• coding history;
• ID3;
• XMP;
• iXML;
• BEXT;
• QuickTime metadata.

ExifTool legge numerose famiglie di metadati audio e, alla data di aggiornamento, supporta anche ID3, RIFF, AIFF, C2PA/JUMBF e molti contenitori multimediali. Sito ufficiale ExifTool.

34.1 Limite

I metadati:

• possono essere assenti;
• possono essere modificati;
• possono essere ereditati;
• possono riferirsi all’ultimo export;
• non identificano automaticamente l’autore.

Vedere il Capitolo 14 — Metadati, EXIF, XMP, C2PA e provenienza dei file.

35. C2PA e provenienza audio

La specifica C2PA 2.4 prevede modalità di incorporamento dei manifesti anche in formati audio:

• WAV e BWF tramite chunk RIFF C2PA;
• MP3 e FLAC compatibili con ID3 tramite oggetto GEOB;
• Ogg Vorbis tramite stream dedicato;
• formati audio BMFF mediante la relativa struttura di box.

Specifica tecnica C2PA 2.4.

Un manifesto valido può documentare:

• integrità;
• provenienza dichiarata;
• applicazioni;
• azioni;
• ingredienti;
• firma.

Non dimostra automaticamente:

• verità delle parole;
• identità della voce;
• liceità;
• completezza della storia;
• assenza di modifiche precedenti al primo manifesto.

L’assenza di C2PA non indica che l’audio sia falso o generato artificialmente.

36. Strumenti principali

36.1 FFmpeg e FFprobe

Per:

• identificazione;
• decodifica;
• estrazione stream;
• packet analysis;
• frame hash;
• statistiche;
• waveform;
• spettrogrammi.

SWGDE ha pubblicato nel 2025 note tecniche specifiche sull’uso di FFmpeg nell’esame forense audio. Technical Notes on FFmpeg for Forensic Audio Examination.

36.2 MediaInfo

Per:

• contenitore;
• codec;
• sample rate;
• bit depth;
• canali;
• bitrate;
• encoder;
• tag.

MediaInfo supporta output testuale, CSV, JSON e altri formati e legge numerosi codec e tag audio. MediaInfo.

36.3 ExifTool

Per:

• metadata;
• gruppi;
• duplicati;
• ID3;
• RIFF;
• QuickTime;
• XMP;
• C2PA.

36.4 Audacity

Per:

• ascolto;
• waveform;
• spettrogramma;
• selezioni;
• annotazioni;
• dati dei campioni.

36.5 Sonic Visualiser

Per:

• visualizzazione dettagliata;
• spettrogrammi;
• confronto;
• annotazioni;
• analisi temporale e frequenziale.

Sonic Visualiser è uno strumento open source dedicato alla visualizzazione, all’analisi e all’annotazione di registrazioni audio. Sonic Visualiser.

36.6 Strumenti specialistici

Possono comprendere:

• software di audio authentication;
• strumenti ENF;
• editor esadecimali;
• analisi codec-specifica;
• MATLAB o Python validato;
• sistemi di confronto del segnale.

37. Registrare le versioni

ffmpeg -version
ffprobe -version
mediainfo --Version
exiftool -ver

Per applicazioni grafiche annotare:

Software:
Versione:
Sistema operativo:
Plugin:
Impostazioni:
Data:

La stessa analisi può produrre risultati differenti con:

• decoder diversi;
• versioni diverse;
• impostazioni differenti;
• librerie aggiornate.

38. Ambiente di ascolto

Utilizzare:

• ambiente silenzioso;
• cuffie cablate conosciute;
• interfaccia audio affidabile;
• livello di ascolto sicuro;
• riproduzione senza effetti;
• canali corretti.

Evitare, quando possibile:

• cuffie Bluetooth;
• equalizzazioni di sistema;
• spatial audio;
• noise cancellation non documentata;
• normalizzazione automatica;
• speaker del laptop;
• servizi di streaming.

ENFSI raccomanda personale specificamente formato, apparecchiatura adeguata, software capace di mostrare waveform, spettro e spettrogramma e condizioni ambientali controllate. Best Practice Manual ENFSI.

39. Prima estrazione con MediaInfo

mediainfo --Output=JSON \
  "registrazione.m4a" \
  > mediainfo.json

Vista testuale completa:

mediainfo --Full \
  "registrazione.m4a" \
  > mediainfo-full.txt

Verificare:

- format;
- codec ID;
- duration;
- sample rate;
- channels;
- bit rate;
- bit rate mode;
- writing application;
- encoded library;
- stream size;
- tags.

40. Prima estrazione con FFprobe

ffprobe \
  -v error \
  -show_error \
  -show_format \
  -show_streams \
  -show_chapters \
  -of json \
  "registrazione.m4a" \
  > ffprobe-full.json

FFprobe raccoglie informazioni su contenitore, stream e metadata e può produrre output strutturato JSON, XML, CSV e altri formati. Documentazione FFprobe.

41. Report FFprobe selettivo

ffprobe \
  -v error \
  -select_streams a:0 \
  -show_entries \
stream=index,codec_name,codec_long_name,profile,sample_fmt,sample_rate,channels,channel_layout,bits_per_sample,bits_per_raw_sample,bit_rate,start_time,duration,time_base:format=format_name,format_long_name,start_time,duration,size,bit_rate:format_tags \
  -of json \
  "registrazione.m4a" \
  > ffprobe-audio.json

Registrare anche gli errori di parsing.

Un file riproducibile da un player può comunque presentare:

• header incoerenti;
• durata errata;
• frame corrotti;
• dati troncati;
• timestamp anomali.

42. Inventario dei pacchetti

ffprobe \
  -v error \
  -select_streams a:0 \
  -show_packets \
  -show_entries \
packet=pts_time,dts_time,duration_time,pos,size,flags \
  -of csv=p=0 \
  "registrazione.m4a" \
  > packets.csv

FFprobe può mostrare i dati di ogni pacchetto e selezionare specifici campi come timestamp, durata, posizione e dimensione. Riferimento FFprobe.

42.1 Utilità

• individuare gap temporali;
• verificare frame mancanti;
• osservare variazioni;
• confrontare due versioni;
• analizzare segmenti.

42.2 Limite

Una variazione di dimensione del pacchetto può essere normale, soprattutto nei codec VBR.

43. Hash dei payload dei pacchetti

ffprobe \
  -v error \
  -select_streams a:0 \
  -show_packets \
  -show_data_hash sha256 \
  -of json \
  "registrazione.m4a" \
  > packet-hashes.json

FFprobe può calcolare un hash del payload dei pacchetti mediante -show_data_hash. Documentazione FFprobe.

Questo output può aiutare a:

• confrontare payload codificati;
• individuare pacchetti identici;
• verificare estrazioni;
• documentare la struttura.

44. Estrazione audio da video senza ricodifica

ffmpeg \
  -v warning \
  -i "video.mp4" \
  -map 0:a:0 \
  -c copy \
  "audio-estratto.mka"

L’uso di un contenitore Matroska audio può consentire di conservare il codec senza doverlo ricodificare.

Registrare:

• file video sorgente;
• stream index;
• codec;
• comando;
• hash dell’output.

L’estrazione non sostituisce la conservazione del video originale.

45. Creare una copia PCM di analisi

ffmpeg \
  -v warning \
  -i "registrazione.m4a" \
  -map 0:a:0 \
  -c:a pcm_s24le \
  -map_metadata -1 \
  "registrazione-analisi.wav"

45.1 Regole

• non impostare un nuovo sample rate se non necessario;
• non cambiare il numero di canali;
• non normalizzare;
• non applicare filtri;
• non sovrascrivere l’originale;
• documentare il sample format scelto.

45.2 Limite

La conversione in PCM:

• facilita l’analisi;
• non recupera informazioni eliminate dal codec;
• non trasforma un file lossy in un originale lossless;
• produce un file derivato.

46. Hash dell’audio decodificato

ffmpeg \
  -v error \
  -i "registrazione.m4a" \
  -map 0:a:0 \
  -c:a pcm_s24le \
  -f framehash \
  "decoded-framehash.sha256"

Per confrontare due file occorre usare:

• stesso decoder;
• stessa versione;
• stesso sample format;
• stessi canali;
• stesso sample rate;
• stessa gestione del padding.

Un framehash coincidente supporta l’identità dei campioni decodificati secondo il processo applicato, non l’identità binaria dei file.

47. ExifTool

exiftool \
  -G0:1:2 \
  -a \
  -s \
  -u \
  -ee \
  -struct \
  "registrazione.m4a" \
  > exiftool-full.txt

JSON:

exiftool \
  -G0:1:2 \
  -a \
  -s \
  -u \
  -ee \
  -struct \
  -json \
  "registrazione.m4a" \
  > exiftool-full.json

L’opzione -a consente di mostrare tag duplicati che altrimenti potrebbero essere soppressi. ExifTool.

48. Analisi esadecimale

xxd \
  -g 1 \
  -l 1024 \
  "registrazione.wav" \
  > header-hex.txt

Per un segmento:

xxd \
  -g 1 \
  -s 4096 \
  -l 512 \
  "registrazione.wav" \
  > segment-hex.txt

L’analisi esadecimale può aiutare a individuare:

• firme;
• chunk;
• tag;
• padding;
• dati aggiunti;
• intestazioni;
• trailer.

Non deve essere svolta senza conoscere la struttura del formato.

49. Waveform

La waveform rappresenta l’ampiezza nel tempo.

Può evidenziare:

• silenzi;
• clipping;
• transienti;
• cambi di livello;
• discontinuità;
• fade;
• segmenti replicati.

Generazione con FFmpeg

ffmpeg \
  -i "registrazione-analisi.wav" \
  -filter_complex "showwavespic=s=2400x600" \
  -frames:v 1 \
  "waveform.png"

Limite

La waveform dipende da:

• zoom;
• scala;
• risoluzione;
• canale;
• rendering.

Un’immagine dell’intero file può nascondere modifiche di pochi millisecondi.

50. Spettrogramma

Lo spettrogramma rappresenta:

tempo
×
frequenza
×
intensità

Può evidenziare:

• rumore;
• armoniche;
• transienti;
• codec;
• cutoff;
• discontinuità;
• riverbero;
• tonalità periodiche;
• artefatti.

Audacity descrive lo spettrogramma come una vista dell’energia nelle diverse bande di frequenza nel tempo e sottolinea il compromesso tra risoluzione temporale e frequenziale determinato dalla dimensione della finestra FFT. Spectrogram View di Audacity.

Generazione con FFmpeg

ffmpeg \
  -i "registrazione-analisi.wav" \
  -lavfi "showspectrumpic=s=2400x1200" \
  "spectrogram.png"

FFmpeg include filtri per waveform e spettrogrammi, tra cui showspectrumpic. Filtri FFmpeg.

51. Parametri dello spettrogramma

Documentare:

- finestra;
- dimensione FFT;
- overlap;
- scala frequenziale;
- range;
- gain;
- dinamica;
- canale;
- frequenza minima;
- frequenza massima;
- colormap.

51.1 Finestra corta

Migliore risoluzione temporale.

Utile per:

• click;
• tagli;
• transienti;
• consonanti.

51.2 Finestra lunga

Migliore risoluzione frequenziale.

Utile per:

• armoniche;
• ENF;
• tonalità;
• rumori periodici.

La stessa registrazione può apparire molto diversa cambiando i parametri.

52. Ascolto critico

L’ascolto deve precedere e accompagnare le misurazioni.

Annotare:

• timestamp;
• parole;
• rumore;
• cambi ambiente;
• click;
• fade;
• interruzioni;
• sovrapposizioni;
• distorsione;
• eventi esterni.

52.1 Procedura

1. ascolto completo senza fermarsi;
2. secondo ascolto con annotazioni;
3. ascolto per canale;
4. ascolto dei punti contestati;
5. confronto con waveform;
6. confronto con spettrogramma;
7. confronto con il contesto.

L’ascolto soggettivo non è sufficiente.

53. Analisi globale e locale

53.1 Globale

Esamina l’intera registrazione:

• struttura;
• codec;
• bitrate;
• livello;
• rumore;
• durata;
• metadata.

53.2 Locale

Esamina punti specifici:

• presunto taglio;
• silenzio;
• cambio parlante;
• click;
• variazione ambientale;
• parola contestata.

Una tecnica globale può non rilevare un montaggio breve.

Una tecnica locale può perdere incoerenze distribuite nell’intero file.

54. Continuità del parlato

Possibili indicatori di discontinuità:

• parola troncata;
• consonante interrotta;
• prosodia innaturale;
• respiro mancante;
• riverbero spezzato;
• rumore ambientale discontinuo;
• transienti;
• cambio improvviso di livello.

Possibili spiegazioni alternative:

• perdita di pacchetto;
• noise gate;
• Voice Activity Detection;
• movimento del microfono;
• pause dell’app;
• buffering;
• clipping;
• sovrapposizione di parlanti.

55. Butt splice

Un butt splice unisce due segmenti senza crossfade.

Può produrre:

• salto di ampiezza;
• click;
• discontinuità della fase;
• cambio del rumore;
• variazione di DC offset;
• transiente anomalo.

Le pratiche ENFSI e SWGDE includono waveform, spettrogramma, potenza, rumore e continuità del segnale tra le analisi utili per rilevare giunzioni. Manuale ENFSI.

Limite

Un click può derivare anche da:

• disturbo elettrico;
• perdita di pacchetto;
• movimento fisico;
• errore del codec;
• dispositivo.

56. Crossfade

Un editor può unire segmenti mediante dissolvenza incrociata.

Il crossfade può:

• evitare il click;
• rendere continua l’ampiezza;
• sovrapporre rumori;
• creare doppio riverbero;
• alterare la fase;
• modificare la densità spettrale.

Un montaggio non deve necessariamente produrre una discontinuità netta.

57. Silenzi

Distinguere:

• silenzio acustico;
• rumore molto basso;
• campioni zero;
• comfort noise;
• muting;
• pausa nativa;
• noise gate;
• segmento eliminato.

Rilevazione orientativa

ffmpeg \
  -hide_banner \
  -i "registrazione-analisi.wav" \
  -af "silencedetect=n=-50dB:d=0.25" \
  -f null - \
  2> silencedetect.txt

Il filtro silencedetect identifica intervalli sotto una soglia scelta per una durata minima. Soglia e durata devono essere definite in relazione al rumore del caso. Filtri audio FFmpeg.

Limite

Un intervallo rilevato come silenzio non dimostra un taglio.

58. Campioni zero

Sequenze di campioni esattamente a zero possono derivare da:

• registratore;
• pausa;
• silenzio digitale inserito;
• padding;
• export;
• packet loss;
• codec decodificato;
• editing.

Verificare:

• lunghezza;
• posizione;
• allineamento ai frame;
• comportamento del dispositivo;
• file di riferimento.

59. Rumore di fondo

Il rumore può contenere:

• traffico;
• ventilazione;
• folla;
• vento;
• rumore elettronico;
• ronzio;
• compressione;
• rumore del microfono.

Possibili indicatori:

• cambi improvvisi;
• spettro differente;
• variazioni di livello;
• rumore duplicato;
• fase incoerente.

Limite

Il rumore può cambiare perché:

• si apre una porta;
• il telefono viene spostato;
• entra un veicolo;
• parte un ventilatore;
• l’AGC cambia guadagno;
• il software applica noise suppression.

Le linee guida ENFSI raccomandano di confrontare le apparenti incoerenze con il contesto, poiché variazioni ambientali possono avere spiegazioni naturali. Manuale ENFSI.

60. Riverbero

Il riverbero dipende da:

• ambiente;
• distanza;
• posizione;
• materiali;
• microfono;
• direzione;
• elaborazione.

Un cambio di riverbero può essere compatibile con:

• montaggio;
• cambio stanza;
• movimento;
• apertura di una porta;
• avvicinamento al microfono;
• noise suppression.

L’analisi deve cercare continuità nel decadimento delle parole e degli eventi acustici.

61. DC offset

Il DC offset è lo spostamento medio del segnale rispetto allo zero.

Può dipendere da:

• elettronica;
• convertitore;
• microfono;
• processing;
• concatenazione;
• editor.

Analisi con FFmpeg

ffmpeg \
  -hide_banner \
  -i "registrazione-analisi.wav" \
  -af astats \
  -f null - \
  2> astats.txt

Il filtro astats può fornire, per canale e complessivamente, statistiche come:

• DC offset;
• bit depth;
• dynamic range;
• peak;
• RMS;
• noise floor;
• zero crossings;
• differenze tra campioni.

Documentazione del filtro astats.

Limite

Un valore globale può nascondere variazioni locali.

62. Potenza e livello

Analizzare:

• peak;
• RMS;
• loudness;
• dinamica;
• crest factor;
• rumore;
• variazioni.

Un cambio di livello può derivare da:

• montaggio;
• AGC;
• distanza;
• orientamento;
• parlante;
• codec;
• normalizzazione.

Non confondere un cambio di livello con un taglio.

63. Clipping

Il clipping può presentarsi come:

• picchi appiattiti;
• distorsione;
• saturazione;
• campioni al valore massimo;
• armoniche aggiunte.

Può derivare da:

• registrazione sovraccarica;
• amplificazione successiva;
• conversione;
• processing;
• altoparlante.

Una modifica che riduce il livello non elimina necessariamente le tracce del clipping precedente.

64. AGC e compressione dinamica

L’Automatic Gain Control modifica il guadagno per mantenere il segnale in un intervallo utile.

Può produrre:

• rumore che aumenta nei silenzi;
• riduzione dei picchi;
• cambi rapidi di livello;
• “pompaggio”;
• diversa percezione dell’ambiente.

Questi fenomeni possono simulare:

• crossfade;
• cambi di stanza;
• montaggi;
• variazioni di microfono.

Chiedere se il dispositivo o software applicava AGC.

65. Noise suppression e noise gate

La riduzione automatica del rumore può:

• eliminare bande;
• produrre suoni metallici;
• interrompere il rumore;
• modificare consonanti;
• creare transizioni artificiali.

Il noise gate può trasformare un rumore continuo in silenzi netti.

Non utilizzare la continuità del rumore come unico criterio quando è presente elaborazione automatica.

66. Analisi stereo

Verificare:

• differenze tra canali;
• fase;
• ritardo;
• livello;
• rumore;
• eventi esclusivi;
• dual mono.

66.1 Possibili anomalie

• un canale cambia e l’altro no;
• fase interrotta;
• segmento mono in un file stereo;
• canali scambiati;
• duplicazione.

66.2 Sistemi telefonici

Un canale può contenere il chiamante e l’altro l’operatore.

Non eseguire un mixdown mono prima di acquisire e analizzare i canali separati.

67. Analisi della fase

FFmpeg include aphasemeter, che misura la relazione di fase tra i canali e può rilevare intervalli mono o fuori fase. Filtro aphasemeter.

Esempio:

ffmpeg \
  -i "stereo.wav" \
  -af "aphasemeter=video=0:phasing=1:duration=1" \
  -f null - \
  2> phase-analysis.txt

Limite

Variazioni di fase possono derivare da:

• movimento;
• stereo artificiale;
• codec;
• beamforming;
• differenze microfoniche;
• montaggio.

68. Analisi del codec

Verificare:

- codec;
- profilo;
- frame;
- packet duration;
- bitrate;
- CBR/VBR;
- padding;
- encoder delay;
- channel mode;
- cutoff;
- errori;
- metadata dell’encoder.

Una registrazione dichiarata come originale di un’app dovrebbe essere confrontata con file prodotti dalla stessa versione dell’applicazione.

69. CBR e VBR

CBR

Bitrate nominalmente costante.

I pacchetti possono comunque avere dimensioni o padding variabili.

VBR

Il bitrate varia secondo la complessità del segnale.

Variazioni di dimensione non indicano automaticamente un montaggio.

Verificare:

• header;
• conteggio frame;
• durata;
• bitrate medio;
• coerenza locale.

70. Cutoff frequenziale

I codec e i sistemi telefonici possono introdurre filtri passa-basso.

Un cutoff può dipendere da:

• bitrate;
• encoder;
• sample rate;
• telephony;
• noise suppression;
• ricodifica.

Un cambio locale del cutoff può essere compatibile con:

• concatenazione;
• doppia codifica;
• cambio codec;
• cambio canale;
• processing.

Non è una prova autonoma.

71. Doppia codifica

La doppia codifica può introdurre:

• artefatti maggiori;
• ulteriori cutoff;
• modifiche ai coefficienti;
• nuove periodicità;
• perdita di transienti;
• cambi nella distribuzione spettrale.

ENFSI include l’analisi delle tracce di doppia codifica tra i metodi per rilevare post-produzione. Manuale ENFSI.

Limite

Una doppia codifica dimostra un passaggio di ricodifica, non necessariamente:

• un taglio;
• una falsificazione;
• una finalità illecita.

72. Ricodifica globale e ricodifica locale

72.1 Globale

Tutto il file è stato esportato nuovamente.

Gli artefatti possono essere uniformi.

72.2 Locale

Un segmento proviene da un’altra codifica e viene inserito nel file.

Possibili segnali:

• cambio cutoff;
• diverso rumore;
• frame grid;
• bitrate locale;
• differente risposta;
• cambi di quantizzazione.

Una ricodifica globale può mascherare differenze locali precedenti.

73. Resampling

Il resampling cambia il sample rate.

Può introdurre:

• interpolazione;
• correlazioni tra campioni;
• filtri;
• cutoff;
• ringing;
• cambi di fase.

Un file a 48 kHz può derivare da una sorgente a 44,1 kHz.

Il sample rate dichiarato non dimostra quello della prima registrazione.

74. Time stretching e pitch shifting

Un editor può modificare:

• durata;
• velocità;
• intonazione;
• formanti.

Possibili tracce:

• transienti smussati;
• periodicità;
• fase;
• riverbero alterato;
• artefatti metallici;
• ripetizioni.

L’analisi richiede:

• confronto;
• misurazioni;
• campioni di riferimento;
• valutazione del codec.

75. Intervalli replicati

Un editor può copiare e incollare:

• rumore;
• silenzio;
• parola;
• frase;
• ambiente.

Possibili metodi:

• cross-correlation;
• confronto waveform;
• fingerprint spettrale;
• sottrazione del segnale;
• ricerca di sequenze identiche.

ENFSI considera gli intervalli perfettamente replicati una possibile traccia di post-produzione e indica confronto visivo, sottrazione e correlazione tra i metodi applicabili. Manuale ENFSI.

Limite

Eventi ripetitivi naturali possono produrre somiglianze.

76. Concatenazione di file

Due registrazioni possono essere unite:

file A
+
file B
=
file C

Cercare:

• struttura del contenitore;
• reset dei frame;
• cambio rumore;
• cambio codec;
• differenza di canali;
• timestamp;
• encoder;
• marker;
• discontinuità.

Un editor può ricodificare l’intero risultato e rendere uniforme la struttura esterna.

77. Inserimento da un’altra fonte

Un segmento può provenire da:

• altro smartphone;
• altra registrazione;
• video;
• messaggio vocale;
• sintetizzatore;
• file musicale.

Possibili indicatori:

• risposta del microfono diversa;
• ambiente differente;
• codec;
• rumore;
• fase;
• sample rate originario;
• riverbero.

La post-produzione può attenuare tali differenze.

78. Registrazione da altoparlante

Un file può essere ottenuto riproducendo un’altra registrazione attraverso:

• speaker;
• cuffia;
• televisore;
• telefono;

e registrandola con un secondo dispositivo.

Possibili indicatori:

• risposta combinata speaker-microfono;
• riverbero ambientale;
• rumore aggiunto;
• banda limitata;
• distorsione;
• eco;
• rumore del locale;
• assenza di metadata originari.

Questa operazione può trasformare un audio modificato in una nuova registrazione tecnicamente continua.

79. Screen recording

Una registrazione dello schermo può catturare:

• audio interno;
• microfono;
• entrambi;
• notifiche;
• silenzi;
• volume variabile.

Il file risultante descrive la sessione di riproduzione, non necessariamente l’origine dell’audio ascoltato.

Acquisire il file riprodotto, quando disponibile.

80. Trasmissione e piattaforme

Il passaggio attraverso:

• social;
• messaggistica;
• videoconferenza;
• email;
• cloud;
• centralino;

può introdurre:

• transcodifica;
• packet loss;
• riduzione banda;
• normalizzazione;
• cambio sample rate;
• metadata nuovi;
• segmentazione.

La provenienza deve essere ricostruita mediante:

• dispositivo;
• database;
• account;
• email;
• log;
• cloud.

81. Miglioramento audio

L’enhancement può comprendere:

• equalizzazione;
• noise reduction;
• de-reverberation;
• channel selection;
• gain;
• filtering;
• spectral editing.

81.1 Regole

- lavorare su copia;
- conservare l’originale;
- registrare parametri;
- produrre una versione non elaborata;
- non usare la versione filtrata per analizzare le tracce distrutte dal filtro;
- indicare ogni trattamento.

Audacity descrive la propria funzione di riduzione del rumore come adatta soprattutto a rumori relativamente costanti e non a ogni tipo di disturbo. Noise Reduction di Audacity.

81.2 Formula

82. Trascrizione

La trascrizione deve essere separata dall’analisi di autenticità.

82.1 Buona pratica

- mantenere timestamp;
- indicare parole incerte;
- distinguere parlanti;
- non correggere il significato;
- indicare sovrapposizioni;
- conservare la versione ascoltata;
- specificare eventuali filtri.

82.2 Marcatori

[non comprensibile]
[voce sovrapposta]
[rumore]
[pausa]
[parola incerta: ...]

82.3 Limite

Una trascrizione non dimostra:

• continuità;
• autenticità;
• identità;
• tono;
• contesto completo.

83. Registrazioni di riferimento

Quando possibile, produrre registrazioni con:

• stessa marca;
• stesso modello;
• stesso firmware;
• stessa app;
• stesse impostazioni;
• stesso codec;
• stessa modalità;
• ambiente simile.

83.1 Test utili

- registrazione continua;
- pausa e ripresa;
- stop e nuova registrazione;
- chiamata in ingresso;
- blocco dello schermo;
- cambio app;
- microfono spostato;
- registrazione silenziosa;
- inoltro nella stessa app;
- export;
- conversione.

ENFSI raccomanda registrazioni di riferimento prodotte, quando possibile, con lo stesso dispositivo, firmware, applicazione, formato e impostazioni. Se il dispositivo probatorio deve essere usato, è opportuno prima acquisirlo e non alterare il supporto contenente il reperto. Manuale ENFSI.

84. Non alterare il dispositivo probatorio

Prima di produrre test:

1. acquisire il dispositivo;
2. preservare memoria e file;
3. documentare lo stato;
4. verificare sincronizzazioni;
5. utilizzare supporto separato;
6. registrare ogni modifica.

Una nuova registrazione può modificare:

• database;
• contatori;
• spazio libero;
• metadata;
• cloud;
• file recenti.

85. Validazione degli strumenti

Il laboratorio dovrebbe verificare:

• accuratezza del parser;
• gestione dei codec;
• timestamp;
• conversioni;
• spettrogrammi;
• risultati su file noti;
• aggiornamenti.

Le pratiche ENFSI raccomandano metodi scientificamente valutati e verificati all’interno del laboratorio, ricordando che alcune tecnologie di ricerca potrebbero non essere ancora adatte all’impiego su casi reali. Manuale ENFSI.

86. Analisi con più strumenti

Le differenze tra strumenti non indicano automaticamente anomalia.

Possono dipendere da:

• arrotondamento;
• parser;
• durata dei pacchetti;
• edit list;
• padding;
• campi differenti.

87. Audacity: procedura di analisi

87.1 Importazione

Importare esclusivamente la copia di analisi.

Audacity consente di importare file audio e visualizzare waveform e spettrogramma. Importing Audio.

87.2 Impostazioni

Annotare:

• versione;
• project rate;
• sample format;
• spectrogram settings;
• zoom;
• canale;
• selezione.

87.3 Non esportare sopra il reperto

L’esportazione produce un nuovo file secondo:

• formato;
• encoding;
• sample rate;
• canali.

Audacity specifica che ciò che viene ascoltato nel progetto viene reso nell’export con le opzioni selezionate. File Export Dialog.

87.4 Campioni numerici

La funzione Sample Data Export può esportare valori dei campioni in TXT, CSV o HTML per una selezione limitata. Sample Data Export.

88. Sonic Visualiser

Può essere utilizzato per:

• waveform;
• spettrogrammi;
• livelli;
• annotazioni temporali;
• confronto di più visualizzazioni.

Documentare:

• versione;
• pane;
• layer;
• window;
• bin;
• scale;
• range;
• zoom;
• selezione.

Lo spettrogramma di Sonic Visualiser rappresenta il contenuto frequenziale nel tempo e consente di modificare proprietà della scala e della visualizzazione. Riferimento Sonic Visualiser.

89. FFmpeg: statistiche e immagini

89.1 Statistiche

ffmpeg \
  -hide_banner \
  -i "analisi.wav" \
  -af astats \
  -f null - \
  2> astats.txt

89.2 Silenzi

ffmpeg \
  -hide_banner \
  -i "analisi.wav" \
  -af "silencedetect=n=-55dB:d=0.20" \
  -f null - \
  2> silences.txt

89.3 Spettrogramma

ffmpeg \
  -i "analisi.wav" \
  -lavfi "showspectrumpic=s=2400x1200" \
  "spectrogram.png"

89.4 Waveform

ffmpeg \
  -i "analisi.wav" \
  -filter_complex "showwavespic=s=2400x600" \
  -frames:v 1 \
  "waveform.png"

Le soglie e le visualizzazioni devono essere documentate e non costituiscono automaticamente risultati forensi.

90. Estrarre un segmento per l’ascolto

Soltanto dalla copia PCM:

ffmpeg \
  -i "registrazione-analisi.wav" \
  -ss "00:01:23.000" \
  -t "00:00:05.000" \
  -c:a pcm_s24le \
  "segmento-01m23s.wav"

Registrare:

• sorgente;
• inizio;
• durata;
• comando;
• hash.

Il segmento non sostituisce il file completo.

91. Confrontare due registrazioni

91.1 Hash binario

sha256sum audio-A.m4a audio-B.m4a

91.2 Hash decodificato

ffmpeg \
  -v error \
  -i "audio-A.m4a" \
  -map 0:a:0 \
  -c:a pcm_s24le \
  -f hash \
  -hash sha256 -

Ripetere per B con gli stessi parametri.

91.3 Confronto temporale

Valutare:

• offset iniziale;
• durata;
• padding;
• segmenti comuni;
• livello;
• canali;
• sample rate.

91.4 Interpretazione

hash binario diverso
+
hash decodificato uguale
=
contenitore o metadata differenti,
audio decodificato coincidente secondo il processo usato

92. Analisi degli errori di decodifica

ffmpeg \
  -v warning \
  -i "registrazione.m4a" \
  -f null - \
  2> decode-warnings.txt

Possibili output:

• invalid data;
• corrupt frame;
• non-monotonous DTS;
• truncated packet;
• missing header;
• concealment.

Un errore può derivare da:

• file danneggiato;
• parser;
• download incompleto;
• montaggio;
• contenitore non standard.

Non equivale automaticamente a manipolazione.

93. Caso pratico 1 — Vocale WhatsApp contestato

Scenario

Un avvocato di Roma consegna un vocale inoltrato e sostiene che una frase sia stata eliminata.

Materiale

- file ricevuto;
- screenshot;
- nessun telefono sorgente;
- nessun database;
- file Ogg/Opus.

Risultati

• struttura Ogg coerente;
• nessun errore evidente;
• variazione di rumore a 14,2 secondi;
• AGC e noise suppression compatibili;
• nessun riferimento dello stesso dispositivo;
• provenienza limitata al file inoltrato.

Conclusione

94. Caso pratico 2 — Memo vocale iPhone con pausa

Scenario

Un cliente di Roma contesta una discontinuità in una registrazione M4A.

Materiale

• iPhone disponibile;
• registrazione nell’app;
• backup;
• file originale;
• stesso modello per test.

Test

- registrazione continua;
- pausa e ripresa;
- stop e nuova registrazione;
- chiamata in ingresso.

Risultati

• la discontinuità è coerente con la pausa nativa;
• struttura e metadati compatibili;
• comportamento replicato nei test.

Conclusione

95. Caso pratico 3 — MP3 ricodificato

Scenario

Un’azienda romana riceve un MP3 dichiarato come registrazione originale di una riunione.

Risultati

- encoder software;
- MP3 VBR;
- cutoff compatibile con codifica precedente;
- metadati creati dopo la riunione;
- nessun dispositivo sorgente;
- nessun file precedente.

Conclusione

96. Caso pratico 4 — Registrazione di call center

Scenario

Un cliente di Roma contesta un silenzio di due secondi in una telefonata.

Risultati

• registrazione dual channel;
• comfort noise;
• Voice Activity Detection;
• silenzio sul canale cliente;
• audio continuo sul canale operatore;
• log PBX coerente.

Conclusione

97. Caso pratico 5 — Audio estratto da un video

Scenario

Un filmato di una telecamera installata a Roma contiene un salto apparente nel parlato.

Risultati

• audio AAC;
• video con frame mancanti;
• timestamp non monotoni;
• audio ricodificato dal software di export;
• estrazione precedente non disponibile.

Conclusione

98. Caso pratico 6 — WAV professionale BWF

Scenario

Una società di produzione romana consegna un file BWF registrato durante un’intervista.

Risultati

- PCM 48 kHz, 24 bit;
- metadata BEXT;
- time reference;
- iXML;
- coding history;
- struttura coerente;
- nessuna discontinuità non spiegata;
- file sul registratore disponibile.

Conclusione

99. Caso pratico 7 — Registrazione da altoparlante

Scenario

Un cliente di Roma consegna un WAV dichiarato come originale di una telefonata.

Risultati

• riverbero ambientale;
• risposta di altoparlante;
• rumore della stanza;
• seconda voce lontana;
• nessun metadata telefonico;
• file prodotto da un registratore digitale.

Conclusione

100. Caso pratico 8 — Concatenazione di due vocali

Scenario

Un file contiene una frase apparentemente continua.

Risultati

- cambio netto del rumore;
- differente cutoff;
- frame structure uniforme dopo ricodifica;
- punto di giunzione a 8,7 secondi;
- due messaggi originali acquisiti;
- contenuto corrispondente ai segmenti.

Conclusione

101. Caso pratico 9 — Audio sottoposto a riduzione del rumore

Scenario

Uno studio legale di Roma consegna una versione “ripulita” di una conversazione.

Risultati

• noise reduction aggressiva;
• rumore di fondo discontinuo;
• consonanti alterate;
• file originale disponibile;
• anomalie assenti nell’originale.

Conclusione

102. Caso pratico 10 — Chiamata in ingresso durante la registrazione

Scenario

Una registrazione smartphone presenta un’interruzione.

Risultati

• log chiamata in ingresso;
• timestamp coerente;
• app sospesa;
• file continua dopo l’evento;
• test di riferimento replicano il comportamento.

Conclusione

103. Caso pratico 11 — Intervallo replicato

Scenario

In una registrazione aziendale di Roma, il rumore di fondo sembra ripetersi.

Risultati

• due segmenti di 1,8 secondi identici a livello di campione;
• stesso rumore e stessi transienti;
• differente parlato sovrapposto assente;
• editor software nei metadati.

Conclusione

104. Caso pratico 12 — Ricodifica senza montaggio

Scenario

Due file hanno hash differenti e bitrate diverso.

Risultati

- audio decodificato allineabile;
- stesso contenuto;
- nessun segmento mancante;
- uno AAC, uno MP3;
- differenze dovute alla compressione.

Conclusione

105. Errori da evitare

1. Analizzare soltanto uno screenshot del player. Non contiene il file.
2. Fidarsi dell’estensione. Può essere errata.
3. Aprire e salvare l’originale. Si modificano struttura e metadati.
4. Convertire prima di calcolare l’hash. Si perde l’identità del reperto ricevuto.
5. Conservare soltanto il WAV di analisi. Si perde il codec originario.
6. Considerare il WAV automaticamente originale. Può essere un export.
7. Considerare MP3 automaticamente manipolato. È soltanto un formato lossy.
8. Considerare la ricodifica prova di taglio. Dimostra un passaggio di encoding.
9. Considerare l’assenza di metadati prova di falsità. Molte piattaforme li rimuovono.
10. Considerare il nome dell’encoder identificativo dell’autore. Indica un software o libreria.
11. Fidarsi di un solo parser. Può interpretare male il formato.
12. Non registrare le versioni degli strumenti. L’analisi non è pienamente riproducibile.
13. Normalizzare il livello prima dell’analisi. Si alterano caratteristiche utili.
14. Ridurre il rumore prima di cercare i tagli. Il filtro può cancellare le tracce.
15. Convertire in mono. Si perdono differenze tra canali.
16. Ricampionare senza necessità. Si introducono nuove correlazioni.
17. Considerare un click prova di montaggio. Può avere origine naturale o tecnica.
18. Considerare un silenzio prova di eliminazione. Può dipendere da VAD, pausa o noise gate.
19. Considerare campioni zero prova certa di editing. Possono derivare dal dispositivo o codec.
20. Fidarsi del solo spettrogramma. La visualizzazione dipende dai parametri.
21. Non documentare la finestra FFT. Il risultato non è riproducibile.
22. Usare uno zoom insufficiente. Si perdono modifiche brevi.
23. Analizzare soltanto un punto locale. Si perde la coerenza globale.
24. Analizzare soltanto l’intero file. Si perdono anomalie locali.
25. Confondere cutoff e taglio temporale. Il cutoff riguarda la frequenza.
26. Confondere doppia codifica e montaggio. Sono fenomeni differenti.
27. Non considerare AGC e noise suppression. Possono simulare discontinuità.
28. Ignorare il sistema telefonico. VoIP e PBX introducono artefatti.
29. Ignorare la messaggistica. L’app può ricodificare.
30. Considerare l’inoltro equivalente al file sorgente. Può cambiare oggetto e metadati.
31. Non acquisire la chat. Si perde il contesto.
32. Non acquisire il dispositivo. Si perdono database e file originali.
33. Produrre test sul dispositivo prima dell’acquisizione. Si modifica il reperto.
34. Usare registrazioni di riferimento con impostazioni diverse. Il confronto perde significato.
35. Non considerare il cambio di stanza. Può spiegare rumore e riverbero.
36. Considerare variazioni di pacchetto prova di editing. Sono normali nei codec VBR.
37. Interpretare un errore decoder come montaggio. Può derivare da corruzione.
38. Ignorare padding ed encoder delay. Possono spiegare scarti di durata.
39. Confondere hash del file e hash decodificato. Misurano oggetti differenti.
40. Confrontare framehash prodotti con impostazioni diverse. Il risultato non è comparabile.
41. Considerare l’assenza di anomalie prova assoluta. Una modifica può non essere rilevabile.
42. Dichiarare il file autentico con un sì o un no. È preferibile valutare compatibilità e limiti.
43. Confondere autenticità e veridicità. Una conversazione continua può essere preparata.
44. Identificare una voce soltanto ascoltandola. Serve metodologia specifica.
45. Utilizzare un detector AI come unica prova. Può produrre falsi positivi e negativi.
46. Considerare l’assenza di C2PA prova contro l’origine artificiale. L’adozione non è universale.
47. Considerare C2PA prova della verità delle parole. Documenta provenienza dichiarata e integrità.
48. Non proteggere la riservatezza. Le registrazioni possono contenere dati sensibili.
49. Diffondere l’audio nella relazione. Può essere non necessario.
50. Scrivere conclusioni giuridiche. Il perito deve rimanere nell’ambito tecnico.

106. Procedura operativa completa

Fase 1 — Autorizzazione

[ ] incarico;
[ ] titolare;
[ ] quesito;
[ ] periodo;
[ ] liceità;
[ ] privacy;
[ ] legale;
[ ] limiti.

Fase 2 — Ricezione

[ ] file;
[ ] dispositivo;
[ ] applicazione;
[ ] contesto;
[ ] versioni;
[ ] punti contestati;
[ ] verbale.

Fase 3 — Conservazione

[ ] originale;
[ ] SHA-256;
[ ] copia di lavoro;
[ ] cartella caso;
[ ] accessi;
[ ] cifratura.

Fase 4 — Identificazione

[ ] estensione;
[ ] firma;
[ ] contenitore;
[ ] codec;
[ ] stream;
[ ] durata;
[ ] canali.

Fase 5 — Metadata

[ ] ExifTool;
[ ] MediaInfo;
[ ] FFprobe;
[ ] tag;
[ ] encoder;
[ ] date;
[ ] C2PA.

Fase 6 — Struttura

[ ] chunk;
[ ] atom;
[ ] page;
[ ] frame;
[ ] packet;
[ ] padding;
[ ] errori;
[ ] trailer.

Fase 7 — Copia PCM

[ ] sample rate preservato;
[ ] canali preservati;
[ ] nessun filtro;
[ ] nessuna normalizzazione;
[ ] comando registrato;
[ ] hash.

Fase 8 — Ascolto

[ ] ambiente;
[ ] cuffie;
[ ] ascolto completo;
[ ] punti contestati;
[ ] annotazioni;
[ ] canali separati.

Fase 9 — Visualizzazione

[ ] waveform;
[ ] spettrogramma;
[ ] parametri;
[ ] zoom globale;
[ ] zoom locale;
[ ] immagini.

Fase 10 — Analisi

[ ] continuità;
[ ] rumore;
[ ] riverbero;
[ ] DC offset;
[ ] livello;
[ ] fase;
[ ] codec;
[ ] doppia codifica;
[ ] replicazioni.

Fase 11 — Riferimenti

[ ] stesso dispositivo;
[ ] stessa app;
[ ] stessa versione;
[ ] stessa impostazione;
[ ] test pausa;
[ ] test chiamata;
[ ] test export.

Fase 12 — Correlazione

[ ] chat;
[ ] email;
[ ] video;
[ ] cloud;
[ ] smartphone;
[ ] log;
[ ] altri file;
[ ] timeline.

Fase 13 — Interpretazione

[ ] dati osservati;
[ ] ipotesi;
[ ] alternative;
[ ] forza;
[ ] limiti;
[ ] fonti mancanti.

Fase 14 — Relazione

[ ] materiale;
[ ] metodo;
[ ] strumenti;
[ ] risultati;
[ ] punti contestati;
[ ] conclusioni;
[ ] allegati;
[ ] hash.

107. Checklist finale

Ricezione

[ ] file più vicino all’originale;
[ ] dispositivo;
[ ] app;
[ ] provenienza;
[ ] quesito;
[ ] autorizzazione.

Integrità

[ ] SHA-256;
[ ] originali protetti;
[ ] copie;
[ ] registro reperti;
[ ] catena di custodia.

Tecnica

[ ] formato;
[ ] codec;
[ ] sample rate;
[ ] canali;
[ ] bitrate;
[ ] metadati;
[ ] struttura;
[ ] pacchetti.

Segnale

[ ] ascolto;
[ ] waveform;
[ ] spettrogramma;
[ ] rumore;
[ ] riverbero;
[ ] DC offset;
[ ] livello;
[ ] fase.

Post-produzione

[ ] tagli;
[ ] crossfade;
[ ] doppia codifica;
[ ] resampling;
[ ] replica;
[ ] concatenazione;
[ ] ricodifica.

Contesto

[ ] chat;
[ ] email;
[ ] cloud;
[ ] dispositivo;
[ ] registrazioni di riferimento;
[ ] eventi noti.

Relazione

[ ] fatti separati dalle ipotesi;
[ ] formule prudenti;
[ ] limiti;
[ ] immagini annotate;
[ ] comandi;
[ ] hash degli output.

108. Output minimo dell’accertamento

1. incarico;
2. verbale di ricezione;
3. registro dei reperti;
4. file originale;
5. hash SHA-256;
6. copia di lavoro;
7. identificazione del formato;
8. MediaInfo JSON;
9. MediaInfo testuale;
10. FFprobe JSON;
11. inventario pacchetti;
12. hash dei payload;
13. ExifTool TXT;
14. ExifTool JSON;
15. copia PCM;
16. framehash;
17. report errori decoder;
18. waveform globale;
19. waveform locale;
20. spettrogramma globale;
21. spettrogrammi locali;
22. statistiche audio;
23. analisi silenzi;
24. analisi canali;
25. analisi fase;
26. segmenti tecnici;
27. registrazioni di riferimento;
28. tabella confronti;
29. timeline;
30. trascrizione, se richiesta;
31. immagini annotate;
32. relazione tecnica;
33. allegati;
34. manifesto hash.

109. Struttura della relazione tecnica

109.1 Incarico

• committente;
• quesito;
• autorizzazione;
• limiti.

109.2 Materiale

• file;
• dispositivo;
• app;
• provenienza;
• dimensione;
• hash.

109.3 Metodo

• strumenti;
• versioni;
• comandi;
• copie;
• ambiente di ascolto;
• parametri.

109.4 Analisi del formato

• contenitore;
• codec;
• stream;
• metadata;
• struttura;
• pacchetti.

109.5 Analisi del segnale

• waveform;
• spettrogramma;
• rumore;
• riverbero;
• livello;
• DC offset;
• fase.

109.6 Punti contestati

Per ogni punto:

timestamp
osservazione
analisi
ipotesi
alternative
limite

109.7 Registrazioni di riferimento

• dispositivo;
• software;
• test;
• risultati;
• comparabilità.

109.8 Correlazione

• chat;
• email;
• video;
• smartphone;
• cloud;
• timeline.

109.9 Conclusioni

Risposte proporzionate al quesito.

110. Modelli di frasi tecniche

110.1 Compatibilità generale

110.2 Nessuna anomalia rilevata

110.3 Discontinuità

110.4 Taglio compatibile

110.5 Pausa nativa

110.6 Ricodifica

110.7 Doppia codifica

110.8 File derivato

110.9 Spettrogramma

110.10 Silenzio

110.11 Rumore

110.12 Riverbero

110.13 DC offset

110.14 Codec

110.15 Hash binario

110.16 Hash decodificato

110.17 Messaggistica

110.18 Registrazione da altoparlante

110.19 Audio telefonico

110.20 Enhancement

110.21 Identità vocale

110.22 C2PA

110.23 Assenza di C2PA

110.24 Limite della copia

110.25 Conclusione prudente

111. Immagini e figure suggerite

112. Riferimenti tecnici e normativi esterni

1. ENFSI — Best Practice Manual for Digital Audio Authenticity Analysis.
2. SWGDE — Best Practices for Digital Audio Authentication, versione 1.3.
3. SWGDE — Best Practices for Forensic Audio, versione 2.5.
4. SWGDE — Technical Notes on FFmpeg for Forensic Audio Examination.
5. FFmpeg — FFprobe Documentation.
6. FFmpeg — Audio and multimedia filters.
7. FFmpeg — Hash, framehash e framemd5.
8. MediaInfo — Dati tecnici e tag per file audio.
9. ExifTool — Metadata audio, ID3, RIFF, AIFF e C2PA.
10. Audacity — Spectrogram View.
11. Audacity — Ricodifica MP3 e perdita generazionale.
12. Sonic Visualiser — Visualizzazione e annotazione audio.
13. MediaArea — BWF MetaEdit.
14. C2PA Technical Specification 2.4 — Incorporamento nei formati audio.
15. Codice civile, articolo 2712.
16. Codice penale, articolo 617-septies.
17. Garante privacy — Regole deontologiche per investigazioni difensive.

113. Collegamenti interni consigliati

Capitolo precedente

• Cloud forensics: Google, Microsoft, Dropbox e backup

Capitolo successivo

• Voice cloning e audio generati con intelligenza artificiale

Capitoli correlati

• Triage iniziale della prova digitale a Roma
• Catena di custodia, hash e verbale tecnico
• Copia forense di hard disk, SSD, pendrive e NAS
• Analisi forense di computer Windows
• Analisi forense di macOS e Linux
• Acquisizione forense di smartphone Android
• Acquisizione forense di iPhone e iPad iOS
• Perizia WhatsApp: messaggi, vocali e allegati
• Telegram, Signal e app di messaggistica forensics
• Recupero dati cancellati per fini probatori
• Analisi forense di email e header
• PEC, ricevute, allegati e prova digitale
• PDF, firme digitali e marche temporali
• Metadati, EXIF, XMP, C2PA e provenienza dei file
• Verifica forense di screenshot e schermate
• Acquisizione di pagine web, social e contenuti online
• Diffamazione online, cyberbullismo, stalking digitale e revenge porn
• Accessi abusivi ad account email, social e cloud
• Truffe online, bonifici fraudolenti e financial cybercrime
• Analisi di log aziendali, firewall, VPN e sistemi cloud
• Incident response forense e ransomware
• Timeline forense e ricostruzione cronologica degli eventi
• Relazione tecnica, CTP informatico e contestazione delle prove digitali

114. Pagine servizio consigliate

/servizi/perizia-informatica-forense-roma/
/servizi/analisi-smartphone-computer/
/servizi/analisi-email-pec-documenti-digitali/
/servizi/acquisizione-pagine-web-social/
/servizi/consulente-tecnico-parte-informatico-roma/
/contatti/

Anchor text consigliati

perizia di autenticità audio a Roma
analisi forense di una registrazione
verifica di tagli e montaggi audio
analisi di un messaggio vocale
perizia su registrazione telefonica
analisi di file WAV e M4A
verifica di ricodifica MP3
analisi spettrografica forense
confronto tra registrazioni audio
verifica di una pausa nella registrazione
analisi audio WhatsApp
consulente informatico forense audio a Roma

115. Box commerciale finale

[ ] registrazioni da smartphone;
[ ] memo vocali;
[ ] telefonate;
[ ] messaggi vocali WhatsApp;
[ ] audio Telegram e Signal;
[ ] registrazioni aziendali;
[ ] file WAV, MP3, M4A, AAC, Opus e AMR;
[ ] audio estratto da video;
[ ] registrazioni di call center;
[ ] file ricodificati;
[ ] sospetti tagli;
[ ] montaggi;
[ ] pause;
[ ] concatenazioni;
[ ] versioni migliorate;
[ ] provenienza e metadati.

116. Conclusione del capitolo

L’autenticità audio non può essere determinata osservando una sola immagine o ascoltando una singola volta il file.

La ricostruzione corretta deve seguire l’intera catena:

evento acustico
→ ambiente
→ microfono
→ dispositivo
→ codec
→ file
→ trasferimento
→ ricodifica
→ acquisizione forense
→ analisi

Ogni passaggio può introdurre caratteristiche tecniche.

La waveform può mostrare un cambiamento di ampiezza.

Lo spettrogramma può mostrare una variazione frequenziale.

Il codec può introdurre artefatti.

La messaggistica può ricodificare.

Il dispositivo può applicare AGC e noise suppression.

Una pausa può essere nativa.

Un silenzio può derivare dalla telefonia.

Una doppia codifica può derivare da un normale export.

Una relazione tecnicamente corretta deve indicare:

- quale file è stato esaminato;
- quale generazione rappresenta;
- come è stato acquisito;
- quali strumenti sono stati utilizzati;
- quali parametri sono stati applicati;
- quali anomalie sono state osservate;
- quali spiegazioni alternative esistono;
- quali fonti non erano disponibili;
- quale forza può essere attribuita alle conclusioni.

Non rilevare un taglio non significa dimostrare che nessuna modifica sia mai avvenuta.

Rilevare una ricodifica non significa dimostrare un inganno.

Rilevare una discontinuità non significa automaticamente identificare l’operazione che l’ha prodotta.

Il ruolo della perizia informatica è trasformare impressioni come:

in una valutazione:

• documentata;
• verificabile;
• riproducibile;
• prudente;
• tecnicamente motivata.

117. Anticipazione del capitolo successivo

Capitolo 25 — Voice cloning e audio generati con intelligenza artificiale

Il prossimo capitolo tratterà:

• sintesi vocale;
• text-to-speech;
• voice conversion;
• clonazione della voce;
• deepfake audio;
• dati di addestramento;
• registrazioni brevi;
• telefonate fraudolente;
• falsi vocali;
• vishing con voce sintetica;
• codec e ricodifiche;
• artefatti temporali e frequenziali;
• prosodia;
• respirazione;
• formanti;
• riverbero;
• coerenza linguistica;
• metadati;
• C2PA;
• detector automatici;
• falsi positivi;
• confronto con campioni autentici;
• acquisizione del file originale;
• provenienza;
• account e piattaforme;
• casi pratici ambientati a Roma;
• limiti nell’attribuzione;
• formule prudenti per la relazione tecnica.

Continua con il Capitolo 25 — Voice cloning e audio generati con intelligenza artificiale →