J'ai commencé à lire des fichiers MP3 en C ++.
Tout s'est bien passé jusqu'à ce que je lisais les spécifications de l'étiquette ID3. Il existe des informations dans l'en-tête ID3V2 sur sa taille stockée dans des entiers dites Synchsafe. C'est un entier de quatre octets où le bit le plus significatif de chaque octet est réglé sur zéro.
J'ai trouvé comment le convertir en entier ordinaire, mais je ne peux pas m'empêcher de me demander pourquoi une valeur entière est stockée de manière aussi compliquée inutilement compliquée.
J'espère qu'il y a quelqu'un qui peut me dire pourquoi il est stocké de cette façon.
3 Réponses :
6.2. Synchsafe entiers
Dans certaines parties de la balise, il n'est pas pratique d'utiliser le schéma de non-corronisation car la taille des données non synchronisées n'est pas connue à l'avance, ce qui est particulièrement problématique avec les descripteurs de taille. La solution dans ID3v2 consiste à utiliser les entiers Synchsafe dans lesquels il ne peut jamais y avoir de faux synchronisations. Les entiers Synchsafe sont des entiers qui gardent son plus haut bit (bit 7) à zéro, rendant sept bits sur huit disponibles. Ainsi, un entier Synchsafe 32 bits peut stocker 28 bits d'informations.
de http://www.id3.org/id3v2.4.0-tructure
Il est étroitement lié à ce qu'ils appellent "non-synchronisation" dans le document donné, vous devriez lire l'ensemble du chapitre 6. Tout cela est lié pour optimiser la compatibilité avec une large gamme de logiciels et de matériel.
Je ne sors pas pourquoi la taille devrait être inconnue. Il existe des champs de données de taille différente, mais il est décrit dans les spécifications où une information particulière est stockée dans le fichier et une taille de cette information.
Pour comprendre pourquoi les entiers Sync-Safe sont utilisés, il est utile de comprendre un peu au format des données MP3 ainsi que de la manière dont un fichier MP3 est lu par un lecteur multimédia. Les données MP3 sont stockées dans un fichier en tant que série de cadres. Chaque image contient un petit bit de musique numérique codée en format MP3 ainsi que certaines métadonnées sur le cadre lui-même. Au début de chaque image MP3 sont 11 bits (parfois 12) toutes définis sur 1. Ceci s'appelle la synchronisation, et c'est le motif qu'un lecteur multimédia cherche lorsque vous essayez de lire un fichier MP3 ou un flux. Si le joueur trouve cette séquence 11 bits, elle sait que sa structure mp3 qui peut être décodée et lue de retour.
voir: www.id3.org/mp3frame p>
Comme vous connaissez une balise ID3 contient des données sur la piste dans son ensemble. Une balise ID3 - Version 2.x 2.x et ultérieure - est située au début d'un fichier ou peut même être intégrée dans un flux MP3 (bien que cela ne soit pas souvent fait). L'en-tête d'une balise ID3 contient un champ de taille 32 bits, ce qui indique combien d'octets sont dans la balise. La valeur maxe un entier non signé 32 bits peut contenir est 0xFFFFFFFF. Donc, si nous écrivions 0xffffffff dans le champ de la taille, nous revendiquons une très grande étiquette (de manière pragmatique trop grande). Lorsque le joueur tente de lire le fichier ou le flux, il recherche la séquence 11 bits d'une trame de données MP3, mais trouve plutôt le champ Taille de l'en-tête ID3 et essaie de lire la balise, car le champ de taille a la première. bits définis. Cela ne semble généralement pas aussi bon, en fonction de vos goûts musicaux. La solution consiste à créer un format entier qui ne contient aucune séquence de 11 bits de tous les 1. D'où le format entier Sync-Safe-Safe. P>
Un entier Sync-Safe peut être converti en entier en C / C ++ en utilisant quelque chose comme les éléments suivants: P>
int ID3_sync_safe_to_int( uint8_t* sync_safe )
{
uint32_t byte0 = sync_safe[0];
uint32_t byte1 = sync_safe[1];
uint32_t byte2 = sync_safe[2];
uint32_t byte3 = sync_safe[3];
return byte0 << 21 | byte1 << 14 | byte2 << 7 | byte3;
}
Merci beaucoup. Je pensais que je ne l'obtiendrai jamais.
En outre, la raison pour laquelle il a été fait de cette façon est que MP3 n'a pas été créé avec des tags de métadonnées à l'esprit. ID3 est arrivé plus tard et devait trouver un moyen de travailler dans les limitations MP3 existantes sans rien ne rien briser.
En plus des réponses ci-dessus, je voudrais ajouter une page de mon blog: http://phoxis.org/2010/05/08/synch-safe/