Standard Midi File
Transcript
Standard Midi File
Standard Midi File Prefazione Questo documento descrive in maniera approfondita il formato SMF, lo standard utilizzato per salvare brani midi su disco. E’ rivolto a tutti gli appassionati del midi e in particolare a coloro che hanno intenzione di sviluppare software musicale che utilizza questo formato. E’ una rielaborazione di alcuni howto, documenti e manuali, sparsi per la rete, rigudanti l’argomento Standard Midi File. Raffaele Scalamadnrè Introduzione Lo Standard Midi File nasce dall’esigenza di poter registrare su file dati midi. E’ stato pensato per garantire la portabilita’ su tutti i tipi di sistemi operativi. E’ semplicemente un file di testo (ASCII), suddiviso in due blocchi di dati: L’ header chunk e il track chunk. L’ header chunk e’ il primo blocco di un midifile e contiene informazioni generali riguardanti il tipo di file, il numero di tracce e il numero tiks per quarto di nota Attualmente esistono tre tipi di formati SMF: - il tipo 0, contiene un unico track chunk che racchiude le informazioni di tutti i canali midi. - il tipo 1, contiene piu’ track chunk, uno per ogni traccia. - il tipo 2 ,contiene piu’ blocchi e si possono registrare piu’ brani in un unico file. Header chunk Come ho già detto l’header chunk è il primo blocco di un midifile. E’ strutturato nella forma seguente: HEX 4D 54 68 64 00 00 00 06 ASCII M t h ff ff nn nn dd dd d I primi 4 byte servono a identificare il midifile I successivi 4 byte indicano la lunghezza dell’header chunk (a partire dal byte successivo) ff ff indica il tipo di midifile (0, 1, 2). nn nn indica il numero di tracce presenti nel midifile (1 se il formato e’ 0). dd dd indica il numero di ticks per quarto di nota. Questa informazione serve a determinare la durata di ogni evento midi in base al valore del delta time.Il delta time è un informazione contenuta all’interno del track chunk e verrà spiegato in seguito. Track chunk Strutturalmente il track chunk è simile all’ header chunk, ma contiene informazioni relative alle tracce della base midi. Ogni traccia contiene eventi midi riguardanti un canale. Un evento può essere: suona una nota, rilascia una nota... etc. un Track chunk si presenta, grosso modo, nella forma seguente: HEX 4D 54 72 6B xx xx xx xx ASCII M t r ... FF 2F 00 k Come per l’header chunk i primi 4 byte servono ad identicicare il blocco I secondi 4 byte servono a indicare la lunghezza del track chunk (partendo dal byte successivo). I successivi byte contengono informazioni di messaggi, di metaeventi o di exlusive messages. FF 2F 00 indica la fine del blocco. - Messaggi Un messaggio è formato da un gruppo di byte indicanti il delta-time e altri byte indicanti il tipo di evento (note on, note off, etc). Il delta time è l’intervallo di tempo espresso in ticks che divide due eventi. Ad esempio se il messaggio in questione dice di suonare una nota per alcuni secondi, le informazioni relative al tempo vengono codificate nel delta-time, mentre le informazioni relative alla nota da suonare vengono memorizzate nei byte successivi. Esempio di messaggio: valore di delta time lunghezza del messaggio messaggio Per ottimizzare lo spazio su disco il valore di delta time viene compresso così da ottenere valori a lunghezza variabile. Il delta time viene scritto su gruppi di byte così suddivisi: Ogni byte è formato da otto bit. Il bit più significativo (il primo partendo da sinistra) serve ad indicare se c’è un altro byte successivo. E’ a 1 se c’è, 0 altrimenti. L’informazione riguardante il delta-time sta nei restanti 7 bit di ogni gruppo di byte. Per capire meglio il metodo di compressione si faccia riferimento alla tabella di seguito riportata. Numeri Hex Codifica Hex Codifica Bin 00000000 00 00000000 00000040 40 01000000 0000007F 7F 01111111 00000080 81 00 10000001 00000000 00003FFF FF 7F 11111111 01111111 00004000 81 80 80 10000001 00000000 10000001 Se due eventi devono essere suonati contemporaneamente il valore di delta-time per quegli eventi è 0. Il delta time rappresenta solo un modo per ricavare un evento midi ma non è esso stesso un evento midi. Per scrivere una procedura in un linguaggio di programmazione che estrae il delta time da un messaggio basta considerare la sommatoria dei 7 bit più significativi (eccetto il primo) per ogni gruppo di byte. - Meta eventi I meta eventi rappresentano informazioni aggiuntive ad un midifile. Non sono eventi midi, ma messaggi che contengono informazioni di vario tipo: copyright, nome delle tracce, la misura del tempo, etc. La struttura è simile a quella di un messaggio di evento midi: valore di delta time FF (inizio del metaevento) tt (tipo di m.e.) ll (lunghezza del m.e.) Meta evento Il valore esadecimale FF indica l’inizio di un metaevento. Il valore tt indica il tipo di metaevento (guarda tabella meta eventi). ll indica la lunghezzda espressa in byte del metaevento. I metaeventi vengono generalmente espressi col codice ASCII. Per fare basi midi che abbiano il testo della canzone(karaoke) si utilizzano i metaeventi. Un altro modo possibile è quello di utilizzare i messaggi di sistema esclusivo. -Messaggi di sistema esclusivo. Servono per mandare messaggi midi esclusivamente ad un apparecchiatura o ad un gruppo di apparecchiature dello stesso tipo. Molte volte viene utilizzato per poter programmare apparecchiature midi. Si possono infatti con questi messaggi impostare alcuni parametri proprietari di uno strumento. Vista l’importanza di questi messaggi c’è il modo di includerli negli standard midi file. La struttura è molto simile a quella dei metaeventi: valore di delta time F0 (inizio del sys-ex) ll (lunghezza del sys-ex) Dati Sys-Ex F7 (fine del sys-ex) Alcuni messaggi, tra i più comuni, di sistema edsclusivo sono riportati nella tabella sys-ex. Ricapitolando, un track chunk contiene informazioni relative ad una traccia midi, il blocco può dcontenere al suo interno messaggi di eventi midi, metaeventi e messaggi di sistema esclusivo. In precedenza si è parlato di tick. E’ la divisionde per quarto di nota rappresentata da un delta-time nel file. Il valore del tick per quarto di nota è indicato nell’header chunk (dd dd), il primo dei due byte indica il formato utilizzato: -24, -25, -29, -30 corrisponde ai quattro standard SMPTE e ai formati Midi Time Code e rappresentano il numero di frames per secondo. Il secondo byte è la risoluzione di un frame. Valori tipici sono: 4 (per la risoluzione Midi Time Code), 8,10,80 (per la risoluzione a bit), oppure 100.Si può utilizzare il sistema basato su tracce time-code oppure quello basato su millisecondi specificando 25 frames/sec e una risoluzione di 40 unita’ per frame. lista di metaeventi Tipo di m.e. Descrizione 01 E’ un evento di testo usato per descrivere il nome di una traccia o il nome di uno strumento. 02 Evento di copyright. In genere si trova come primo evento della traccia 1 03 Evento di testo che indica il nome della traccia.In un midifile formato 0, o inserito nella prima traccia in un file formato 1, indica il nome del brano 04 Evento di testo. Serve ad indicare il nome di uno strumento 05 Evento di testo per inserire i testi nel brano (in sillabe) 06 Evento di testo che in un punto stabilito della sequenza lo marca con il testo 2F Fine della traccia 51 Evento di tempo. indica quanti millisecondi ci devono essere per quarto di nota. 58 Evento per descrivere la divisione del brano 59 Evento indicante la tonalita’ lista di sys-ex Messaggio di systema esclusivo Descrizione F0 7E 7F 09 01 F7 GM ON, resetta i parametri dello strumento F0 43 10 4C 00 00 7E 00 F7 XG ON, resetta i parametri di uno strumento XG compatibile (Yamaha), preparandolo a ricevere messaggi XG F0 41 10 42 12 40 00 7F 00 41 F7 GS ON, resetta i parametri di uno strmento GS compatibile (Roland, Yamaha), preparandolo a rievere messaggi GS. Note sul copyright Tutti i diritti sono riservati. Questo documento è distribuito gratuitamente a scopo didattico.Nessuna parte di questo documento può essere riprodotta, memorizzata in sistemi d’archivio, o trasmessa in qualsiasi altra forma o mezzo, elettronico, meccanico, fotocopia, a scopo di lucro o senza la preventiva autorizzazione scritta dell’autore. Raffaele Scalamandrè , e-mail: [email protected] Bologna 27/03/2000