RFC3003 Type de support audio/mpeg Nilsson

Groupe de travail Réseau

M. Nilsson

Request for Comments : 3003

novembre 2000

Catégorie : En cours de normalisation

Traduction Claude Brière de L’Isle



Type de support audio/mpeg


Statut de ce mémoire

Le présent document spécifie un protocole Internet en cours de normalisation pour la communauté de l’Internet, et appelle à des discussions et des suggestions pour son amélioration. Prière de se reporter à l’édition actuelle du STD 1 "Normes des protocoles officiels de l’Internet" pour connaître l’état de normalisation et le statut de ce protocole. La distribution du présent mémoire n’est soumise à aucune restriction.


Notice de copyright

Copyright (C) The Internet Society (2000). Tous droits réservés.


Résumé

Les couches audio des normes MPEG-1 et MPEG-2 sont fréquemment utilisées sur l’Internet, mais il n’y a pas de type uniforme d’extension de messagerie multi objets Internet (MIME, Multipurpose Internet Mail Extension) pour ces fichiers. L’intention du présent document est de définir le type de support audio/mpeg pour se référer à cette sorte de contenu.


Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMETE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119].


1. Audio MPEG


La compression audio définie comme couches I, II et III dans les normes [MPEG-1] et [MPEG-2] est une méthode populaire de compression de l’audio avec une faible perte de qualité. L’audio compressé est partagé en plusieurs petites trames de données, chacune contenant un en-tête de trame et des données audio compressées.


Le type MIME audio/mpeg définit un flux d’octets élémentaire contenant des trames MPEG conformes à [MPEG-1] et [MPEG-2], éventuellement intercalées avec des données non MPEG. Les données non MPEG sont des données sans synchronisation MPEG ou qu’il n’est par ailleurs pas possible de décompresser sans erreur.


Normalement, les méta données audio MPEG sont enchaînées avec le flux MPEG, par exemple, le format ID3 de méta données met un bloc de données de 128 octets à la fin du flux, tandis que ID3v2 [ID3V2] ajoute un bloc de données de taille variable en tête du flux.


Note : l’audio MPEG n’a pas été conçu comme un format de fichier mais comme un format pour la transmission de flux audios. À ce titre, il n’a aucune façon bien définie d’inclure des méta données dans des informations audio. Certains produits incorporent les méta données en utilisant des trames d’amplitude zéro ou déguisées en erreurs de transmission. D’autres incorporent les données MPEG dans le format WAV.


Note : le type MIME audio/MPA est utilisé en plus de audio/mpeg. Le sous-type MPA [RFC1890] se réfère à l’audio MPEG lorsque il est segmenté et envoyé comme charge utile du protocole de transport en temps réel (RTP, Realtime Transport Protocol).


2. Informations d’enregistrement


To: ietf-types@iana.org

Objet : Enregistrement du type de support MIME audio/mpeg

Nom du type de support MIME : audio

Nom de sous-type MIME : mpeg

Paramètres exigés : aucun

Paramètres facultatifs : aucun

Considérations de codage : pour l’utilisation sur l’Internet on suppose que les couches inférieures veillent aux erreurs de transmission, de sorte que les données audio/mpeg PEUVENT inclure des trames MPEG générées sans vérification facultative de redondance cyclique (CRC) pour une qualité audio améliorée. Les données audio MPEG sont binaires, et doivent être codées pour un transport non binaire ; le codage Base64 convient pour la messagerie électronique. Noter que les données audio MPEG ne se compressent pas facilement en utilisant une compression sans perte.


Considérations pour la sécurité : MPEG est un format de données étiqueté, et certaines étiquettes sont disponibles pour utilisation privée. À ce titre du matériel arbitraire pourrait éventuellement être transféré dans le flux MPEG, incluant du contenu exécutable. Les données étiquetées qui incluent du contenu exécutable NE DEVRAIENT jamais être envoyées et NE DOIVENT PAS être exécutées si elles sont reçues.


Note : L’exigence qu’un tel contenu ne soit pas exécuté à réception est particulièrement importante car il existe des situations où le contenu va être généré de façon indépendante et pourrait donc comporter un contenu exécutable dont l’envoyeur n’est pas conscient.


Les objets audio/mpeg ne sont pas signés ni chiffrés en interne. Des mécanismes externes de sécurité doivent être employés pour assurer la confidentialité du contenu


Considérations d’interopérabilité : MPEG audio s’est révélé largement interopérable sur les plateformes informatiques.


Spécification publiée : voir [MPEG-1] et [MPEG-2]


Applications qui utilisent ce type de support : MPEG audio est neutre pour l’appareil, la plateforme et le fabricant et est pris en charge par une large gamme de codeurs et décodeurs (joueurs).


Informations supplémentaires :

Numéro magique : aucun

Extensions de fichier : .mp1, .mp2, .mp3

Code de type de fichier Macintosh : MPEG

Identifiant d’objets ou OID : aucun


Adresse personnelle & de messagerie à contacter pour plus d’informations : l’auteur de ce document.


Utilisation prévue : courante


Auteur/contrôleur des changements : Martin Nilsson (voir section 5)


3. Considérations pour la sécurité


Les considérations de sécurité sont exposées dans la partie considérations de sécurité de l’enregistrement MIME à la section 2.


4. Références


[ID3v2] Martin Nilsson, "ID3 tag version 2.3.0". <url:http://www.id3.org/id3v2.3.0.txt>


[MPEG-1] ISO/CEI 11172-3:1993. "Codage des images animées et de l’audio associé pour support de mémorisation numérique jusqu’à environ 1,5 Mbit/s, Partie 3 : Audio". Comité technique / sous-comité : JTC 1 / SC 29


[MPEG-2] ISO/CEI 13818-3:1995 "Codage générique pour les images animées et les informations audio associées, Partie 3 : Audio". Comité technique / sous-comité : JTC 1 / SC 29


ISO/IEC DIS 13818-3 "Generic coding of moving pictures and associated audio information, Part 3: Audio (Revision de ISO/IEC 13818-3:1995)"


[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.


5. Adresse de l’auteur


Martin Nilsson

Rydsvagen 246 C. 30

S-584 34 Linkoping

Sweden

mél : nilsson@id3.org


6. Déclaration complète de droits de reproduction


Copyright (C) The Internet Society (2000). Tous droits réservés.


Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.


Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.


Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.


Remerciement

Le financement de la fonction d’éditeur des RFC est actuellement fourni par la Internet Society.

page - 3 -