<figure><img src="image_62.png" /></figure>

## 4.7. EBU-STL

### Description

Le format EBU-STL est un format binaire qui fournit le contenu des sous-titres et leur positionnement temporel vis-à-vis d'une vidéo. Il est maintenu par l'EBU (European Broadcasting Union) qui le documente très précisément.

Il permet l'usage de nombreux alphabets par la définition de plusieurs types d'encodage, le positionnement précis des sous-titres ainsi que la subdivision des sous-titres en plusieurs fichiers (par exemple, pour suivre la subdivision en bobines).

Sa grande stabilité et sa standardisation en font un bon candidat pour la préservation, malgré le faible nombre d'outils qui peuvent le traiter.

### Qualité et caractéristiques du flux

Le format EBU-STL permet d'encoder un seul flux de sous-titres dans une langue spécifiée. Ses fonctionnalités de sous-titrage (style, positionnement spatial) sont équivalentes à celles de SRT, mais il définit en plus un formalisme de métadonnées internes.

### Sociabilité

Le format EBU-STL est couramment utilisé dans l'industrie broadcast. Il est également utilisé dans la production cinématographique, en particulier en raison de sa compatibilité avec les équipements de diffusion.

### Relations à d'autres formats

Ce format tend à être remplacé par le format EBU-TT. Un document de l'EBU, le TECH 3360, explicite la conversion vers ce format.

### Versions

Bien que défini très précisément par l'EBU, des usages non standards existent, en particulier pour accepter l'UTF-8 pour l'encodage des textes.

### Conteneur

Le format EBU STL se présente toujours dans un fichier dédié, séparé du contenu vidéo associé.

### Contenu

La principale information sur le flux textuel est son encodage qui, si l'on respecte la norme, doit être parmi les cinq suivants :

- ISO 6937/2-1983/Add.1:1989 (écritures latines);

- ISO 8859/5-1988 (cyrillique);

- ISO 8859/6-1987 (arabe);

- ISO 8859/7-1987 (grec);

- ISO 8859/8-1988 (hébreu).

Il est important de noter que l'encodage « habituel » est donc l'ISO 6937/2-1983/Add.1:1989 qui est un encodage rarement supporté nativement par les langages de programmation et que les diacritiques sont représentés par combinaison de symboles (par exemple, le caractère « ê » est codé sur 2 octets, C3h et 65h). Par ailleurs, les valeurs de 80h à 9Fh sont réservées aux styles (italiques, soulignés, encadrés) ou au remplissage (« padding »).

### Organisme de maintenance et documentation de référence

Ce format est maintenu par l'EBU (European Broadcasting Union).

Le standard est défini dans la note technique 3264-E de novembre 1991.

### Identifiants

Extension: .stl

Type MIME non officiel: application/x-ebu-stl
<figure><img src="image_63.png" /></figure>

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q27979370</td></tr><tr><td>PRONOM</td><td>fmt/1940</td></tr><tr><td>Just Solve the File Format Problem</td><td>EBU_STL</td></tr></tbody></table>

## Caractéristiques techniques

Le format est relativement simple (CPO-SIM) puisqu'il tient complètement dans un document de 31 pages.

Comme il s'agit d'un format binaire, il est plutôt compact (CPO-COM), peu robuste (CPO-ROB) puisqu'il n'y a pas de point de reprise et pas de redondance et moins transparent que son successeur textuel, EBU-TT.

Il n'inclut pas de mécanismes de protection (CPO-PRO).

## Métadonnées internes

Le format inclut un en-tête général permettant de fournir de nombreuses informations de langue, de titre, d'auteur, d'éditeur et de traducteur, le cas échéant.

De plus, il est possible de fournir des informations libres en ajoutant des « sous-titres » localisés temporellement avant la date de début de la séquence.

## Outils connus par la BnF

Le format est identifié par les outils DROID et Unix file.

L'outil d'analyse et d'extraction de métadonnées techniques pour la BnF est MediaInfo.

Il est facilement convertible en SRT avec des scripts.

## Usage ou présence dans les collections de la BnF

Ce format est utilisé à la BnF comme l'un des formats possibles de fourniture des sous-titres pour le dépôt légal de l'image animée.
<figure><img src="image_64.png" /></figure>

## 4.8. EBU-TT

### Description

Le format EBU-TT est un format textuel basé sur XML qui fournit le contenu des sous-titres et leur positionnement temporel vis-à-vis d'une vidéo. Il est maintenu par l'EBU (European Broadcasting Union).

Basé sur XML, il prend totalement en charge l'encodage des caractères (généralement en UTF-8) et offre un large éventail d'éléments pour définir le style, le positionnement et la langue des sous-titres. Il peut même embarquer plusieurs langues dans le même fichier.

Sa grande stabilité, sa transparence et sa standardisation en font un bon candidat pour la préservation.

### Sociabilité

Le format EBU-TT est largement utilisé dans des environnements web, des applications multimédias et des services de streaming. Son formalisme XML lui permet d'intégrer des workflows de production (validation, contrôle qualité, caractérisation, etc.).

### Relations à d'autres formats

Ce format est une spécialisation du format TTML v1 développé par le W3C.

Il est conçu pour remplacer le format binaire EBU-STL.

### Versions

Le format EBU-TT ne dispose pas de version particulière.

### Conteneur

Le format EBU TT se présente toujours dans un fichier dédié, séparé du contenu vidéo associé.

### Contenu

Un fichier EBU-TT utilise la syntaxe XML et comprend des balises pour décrire différentes composantes des sous-titres. La balise `<tt>` englobe tout le document, et les balises `<p>` définissent les paragraphes de texte avec des attributs de temps (`begin` et `end`) pour spécifier la synchronisation.

Par ailleurs, des espaces de noms séparés permettent de prendre en charge les différents aspects : paramètres, styles, métadonnées (langue, par exemple).

### Organisme de maintenance et documentation de référence

Ce format est maintenu par l'EBU (European Broadcasting Union).

Le standard est défini dans une série de notes sur le format EBU-TT, en particulier :

- La partie 1 de la note technique 3350 : Part 1: EBU-TT Subtitling format definition de mai 2017 ;

- Les spécificités de distribution dans la note technique 3380 : EBU-TT-D: Subtitling Distribution Format de mai 2018.

### Identifiants

Extension : `.ttml`

Type MIME : `application/ttml+xml`

Espace de noms principal : `http://www.w3.org/ns/ttml`

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q27979371</td></tr><tr><td>Just Solve the File Format Problem</td><td>EBU_Timed Text</td></tr></tbody></table>
<figure><img src="image_65.png" /></figure>

## Caractéristiques techniques

Le format est assez complexe puisqu'il est basé sur XML et utilise de nombreux espaces de nom (CPO-SIM) mais il reste transparent (CPO-TRA).

S'agissant d'un format basé sur XML, le format est verbeux (CPO-COM), mais assez robuste (CPO-ROB) du fait de la redondance d'information et du caractère textuel du flux qui permet de le contrôler et potentiellement de le corriger.

Il n'inclut pas de mécanismes de protection (CPO-PRO).

## Métadonnées internes

Le format prévoit un espace de nom complet permettant de fournir de nombreuses informations de langue, de titre, d'auteur, d'éditeur et de traducteur, le cas échéant. Une note technique 3390, Part M: Metadata Definitions est dédiée à cet aspect.

## Outils connus par la BnF

Le format est identifié par les outils DROID et Unix file comme du format TTML v1.

Tous les outils permettant de contrôler ou manipuler le XML sont utilisables directement.

L'outil d'analyse et d'extraction de métadonnées techniques pour la BnF est MediaInfo.

## Usage ou présence dans les collections de la BnF

Ce format est utilisé à la BnF comme l'un des formats possibles de fourniture des sous-titres pour le dépôt légal de l'image animée.
<figure><img src="image_66.png" /></figure>

## 4.9. Format textuel Office Open XML (DOCX)

### Description

Le format de traitement de texte Office Open XML (OOXML), également nommé « DOCX » selon son extension la plus courante, est une des déclinaisons des formats OOXML pour les documents de traitement de texte. Les formats OOXML ont été créés en 2007 par Microsoft en remplacement de leur équivalent binaire comme formats de production de leur suite bureautique Microsoft Office. Outre son contenu textuel formaté, le format peut contenir une grande diversité de contenus (images, tableaux, graphiques, hyperliens, etc.).

Le format est documenté par la norme ISO/IEC DIS 29500 depuis 2008. Ce processus de normalisation est une réponse de Microsoft à l'adoption par l'ISO en 2006 du format de fichier bureautique ouvert OpenDocument Format. La reconnaissance officielle d'OOXML a fait l'objet de vifs débats portant sur la difficulté de la transposer à d'autres suites bureautiques et, donc, sur les limites de son ouverture.

Du fait de sa structure XML, le format DOCX permet une plus grande facilité de récupération des données par rapport à son prédécesseur DOC : ainsi, même si un document est partiellement corrompu, le contenu non corrompu est potentiellement récupérable. Sa compression facilite par ailleurs le stockage et le partage. Par ailleurs, reposant sur un standard réputé relativement ouvert, il est censé être accessible et modifiable par la plupart des logiciels en dehors de son producteur Microsoft.

### Sociabilité

Microsoft Office est actuellement la suite bureautique la plus connue et la plus utilisée dans le monde. Outre le logiciel Microsoft Word, d'autres applications déclarent le gérer, au moins partiellement : Google Docs, OpenOffice, LibreOffice, etc., même si cette compatibilité fait débat.

En 2016, la version 2.0 du Référentiel général d'interopérabilité (RGI), décrivant les normes et bonnes pratiques communes aux administrations publiques françaises dans le domaine informatique, assigne au format OOXML le statut « en observation ». Cela signifie que « son application est à prendre avec précaution ».

### Relations à d'autres formats

Le format est une spécialisation du format ZIP. Tous les outils permettant d'exploiter des fichiers ZIP fonctionnent donc sur DOCX - il est possible de vérifier l'intégrité des composants du DOCX avec la commande `zip -T`, d'afficher la structure interne du fichier avec la commande `unzip -l`, etc.

Le format remplace, à partir de la version du pack Office 2007, le format binaire non documenté DOC, le plus utilisé en bureautique dans les années 1990, mais non normalisé et jugé trop lourd en termes de stockage d'information.

Les fichiers XML contenus dans un fichier DOCX sont fondés sur la syntaxe WordprocessingML. Le logiciel Word peut, depuis sa version 2003, enregistrer des documents dans ce format XML seul, mais ce dernier est limité dans l'expressivité et les contenus qu'il peut embarquer. On se reportera à cette section de la fiche Wikipedia anglophone traitant de « Microsoft Office XML Formats » afin d'avoir une vue des différences avec le format conteneur DOCX.

### Versions

Il existe deux variantes de DOCX :

- La première dite « transitoire », intégrée à partir de Office 2007, n'est pas compatible avec la norme ISO/IEC DIS 29500 car cette dernière, adoptée seulement en 2008, fit l'objet de plusieurs corrections à la demande de l'ISO. La variante transitoire permet une rétrocompatibilité avec le format DOC, et l'importance accordée à cette dernière caractéristique a amené certains éditeurs de solutions logicielles à la préférer. Elle est de ce fait la variante la plus répandue.

- La variante suivante, dite « stricte », a été intégrée progressivement à partir d'Office 2010. Elle suit intégralement la norme ISO. Elle n'est pas rétrocompatible avec les versions de Word antérieures à 2010, sinon à installer un convertisseur proposé par Microsoft. Elle est lisible mais non productible par Microsoft Office 2010. Les versions de Microsoft Word depuis Office 2013 sont capables de la produire, bien que la version transitoire demeure le format par défaut de Word, si ce comportement n'est pas reparamétré par l'utilisateur (Fichiers > Options > Enregistrement > Document Open XML Strict).
<figure><img src="image_67.png" /></figure>

La cohabitation des différentes variantes de DOCX à travers différentes versions de la suite Microsoft Office (au sein desquelles le degré d'implémentation de la norme varie) a pu contraindre à des conversions de format provoquant une perte de métadonnées. A pu également être constatée une corruption des fichiers lors de leurs échanges entre certaines versions de Microsoft Office et des logiciels libres suivant la norme stricte (par exemple entre Office 2010 et LibreOffice).

## Contenu

### Anatomie

Le format est composé de plusieurs fichiers structurés selon la syntaxe XML et compressés avec l'algorithme Deflate sous forme d'un unique conteneur ZIP. Les fichiers représentent le contenu, le style, les paramètres du texte, etc. Le contenu textuel principal du DOCX se trouve dans le fichier word/document.xml. L'anatomie d'un fichier DOCX est décrite à cette page. On trouvera également une information sur la structure de base des fichiers WordprocessingML à cette adresse.

### Contenus embarqués (image, son, vidéo, fichier arbitraire)

Il est possible d'inclure dans un fichier DOCX des contenus de nature diverse : images (JPEG, TIFF, PNG, SVG, etc.), documents PDF, fichiers bureautiques du pack Microsoft Office éditables directement depuis le fichier DOCX (PPTX, XLSX, etc.), vidéos, et de manière générale tout fichier quel que soit son format. Ces fichiers sont accessibles en ouvrant le fichier DOCX avec un gestionnaire de fichiers conteneurs, dans un répertoire word/media ou word/embeddings. Néanmoins, leur nom de fichier originel n'est pas préservé. Certains de ces fichiers étant conservés sous une forme binaire d'objet OLE, il est nécessaire d'utiliser un outil comme Apache Tika pour en extraire une version utilisable.

### Polices

Le format peut embarquer ou non les polices utilisées si on le paramètre dans ce but (Fichier > Options > Enregistrement > Préserver la fidélité lors du partage du document). En l'absence des polices utilisées sur l'équipement de lecture, la mise en page voire la lisibilité peuvent être fortement altérées.

### Organisme de maintenance et documentation de référence

En 2006, les formats OOXML ont été normatisés par la European association for standardizing information and communication systems (ECMA) sous l'identifiant ECMA-376. Cette organisation diffuse les spécifications gratuitement sur cette page.

Les formats Office Open XML sont également normalisés à l'ISO sous l'identifiant ISO/IEC 29500. Cette norme est développée par un unique éditeur de logiciels propriétaires : Microsoft. Le statut de norme internationale adoptée par l'ISO garantit cependant qu'il s'agit d'une norme dûment documentée et librement utilisable en dehors des logiciels de Microsoft.

Certains experts ont cependant fait remarquer que les spécifications de la norme OOXML sont anormalement complexes par rapport aux autres normes (le document de la version ISO/IEC 29500-1:2016 fait plus de cinq mille pages !), car OOXML obéit à la logique et à l'histoire propre de son développeur. Du fait de cette complexité, il n'est pas complètement garanti que OOXML puisse être parfaitement et intégralement implémentée en dehors de Microsoft sans implémenter également des parties de la suite Microsoft Office elle-même. D'autant moins que la norme contient des références à des technologies propriétaires ainsi que des marques commerciales.

### Identifiants

Extensions : .docx, .docm (permettant d'embarquer des macros), .dotx/.dotm (modèle destiné à embarquer des styles).

<table><thead><tr><td>Type</td><td>Extension</td><td>Type MIME</td></tr></thead><tbody><tr><td>Document Word</td><td>.docx</td><td>application/vnd.openxmlformats-officedocument.wordprocessingml document</td></tr><tr><td>Modèle Word</td><td>.dotx</td><td>application/vnd.openxmlformats-officedocument.wordprocessingml.template</td></tr></tbody></table>
<figure><img src="image_68.png" /></figure>

<table><tr><td>Document Word prenant en charge les macros</td><td>.docm</td><td>application/vnd.ms-word document.macroenabled.12</td></tr><tr><td>Modèle Word prenant en charge les macros</td><td>.dotm</td><td>application/vnd.ms-word.template.macroenabled.12</td></tr></table>

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q3033641 (entrée générale)<br/>Q26207818 (strict)</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000400 (strict)<br/>fdd000397 (transitoire)</td></tr><tr><td>PRONOM</td><td>fmt/412 (entrée globale, PUID renvoyé de fait pour les DOCX transitional)<br/>fmt/1827 (strict)<br/>fmt/523 (DOCM avec macros)</td></tr><tr><td>Just Solve the File Format Problem</td><td>DOCX</td></tr></tbody></table>

## Caractéristiques techniques

### Poids maximal

La taille d'un fichier .docx peut techniquement aller jusqu'à 512 Mo, mais elle est souvent limitée d'abord par les ressources du système d'exploitation.

### Modifications involontaires

Les fichiers ouverts dans le logiciel Word, dont les fichiers DOCX, sont souvent modifiés, même sans action consciente de l'utilisateur ice. Ce comportement pose des problèmes car la date de dernière modification associée au fichier, l'empreinte numérique voire les personnes associées (« auteur », « dernière modification par ») peuvent alors être altérées. Pour éviter ces comportements lors de l'ouverture d'un fichier Word en vue d'une simple visualisation, il est recommandé d'appliquer une des solutions suivantes :

- Mettre le fichier / le dossier en lecture seule (clic droit > Propriétés > Lecture seule) ;

- Obliger Word à n'ouvrir les fichiers qu'en mode lecture seule via Fichiers > Options > Centre de gestion de la confidentialité > Paramètres du centre de gestion de la confidentialité > Paramètres de blocage des fichiers.

### Macros embarquées

Les documents OOXML peuvent embarquer des macros, petits programmes définissant un ensemble d'actions automatisables. Les macros peuvent être définies par une interaction de l'utilisateur ice avec l'interface par le biais du clavier et de la souris, ou être créées/modifiées directement dans l'interface Développeur à l'aide du langage de programmation Visual Basic. Les fichiers textuels OOXML dont les macros sont autorisées portent l'extension .dotm. En cas d'enregistrement dans un format autre que .dotm, les macros sont généralement perdues. Cette fonctionnalité a été largement utilisée pour créer des virus, aussi les outils de cybersécurité tels que ooletools peuvent-ils servir à identifier des risques de préservation liés aux macros ou à l'appel de contenus externes.

### Fichier de styles

Un fichier DOCX peut être utilisé pour embarquer une feuille de styles. La structure d'un tel fichier ne diffère pas de celui d'un fichier DOCX habituel mais l'usage attendu du fichier est marqué par l'extension .dotx ou .dotm (« t » pour template).
<figure><img src="image_69.png" /></figure>

## Métadonnées internes

Les fichiers DOCX conservent, comme leur ancêtre DOC, des métadonnées telles que le temps d'édition et le nombre d'enregistrements successifs. Ces métadonnées peuvent être consultées par un simple clic droit sur le fichier (Propriétés > Détails) ou être extraites par un outil tel qu'Exiftool.

Les métadonnées techniques indiquent seulement la version du pack Office utilisé sans spécification sur le format précis d'enregistrement du fichier (norme OOXML transitoire ou « stricte »).

## Outils connus par la BnF

- **Exploration** : les gestionnaires de fichiers conteneurs tels que 7-Zip peuvent ouvrir les fichiers DOCX comme des fichiers ZIP et accéder à leur contenu ;

- **Caractérisation** : Exiftool est capable d'analyser les propriétés des fichiers DOCX, tout comme Apache Tika avec l'option `-m` ;

- **Extraction** : Apache Tika est capable d'extraire le texte avec l'option `-t` et les fichiers inclus (images, mais aussi tout fichier encapsulé) avec l'option `-z` (Tika fournit à cette occasion le type MIME des éléments extraits).

## Usage ou présence dans les collections de la BnF

Des fichiers DOCX sont versés au titre des dons et acquisitions nativement numériques, en particulier dans le cas de fonds d'archives numériques. Par ailleurs, on en trouve également dans les archives du web.
<figure><img src="image_70.png" /></figure>

## 4.10. EPUB

### Description

EPUB est un format ouvert de distribution et d'échange pour les publications et documents numériques. Il permet d'empaqueter sous forme d'un fichier unique compressé des contenus textuels, audio et images.

Pour répondre à l'arrivée des nouveaux petits écrans mobiles (2004 : premier e-reader ; 2007 : premiers Kindle et iPhone ; 2010 : premier iPad) EPUB, dès sa normalisation en 2007, emprunte au web ses langages et sa logique fondamentale : ses contenus sont enrichis sémantiquement grâce à une structuration (X)HTML, et mis en forme grâce à CSS pour une adaptabilité maximale au dispositif d'affichage.

Une version EPUB 2.0.1 est approuvée en 2010. Suivent EPUB 3.0 en octobre 2011, EPUB 3.0.1 en juin 2014, EPUB 3.1 en janvier 2017, et EPUB 3.2 en 2019.

En 2020, et malgré l'ancienneté notable d'EPUB 3, c'est toujours EPUB 2.0.1 qui reste majoritaire dans la production française.

### Sociabilité

Dès 2010, EPUB est progressivement, puis très vite unanimement, adopté par les éditeurs français et les autres acteurs de la chaîne du livre numérique (diffuseurs et distributeurs).

Une exception est à signaler : la société Amazon, premier revendeur de livres numériques sur le marché français, exploite des formats propriétaires (dont la production repose très majoritairement sur une conversion d'EPUB).

### Relations à d'autres formats

**ZIP** : l'extension « .epub » cache un fichier ZIP conforme. Une publication EPUB peut donc être décompressée et ses contenus ainsi rendus disponibles (en l'absence de DRM, voir infra).

**XML et HTML** : à sa racine, une publication EPUB présente un fichier « container.xml » dans un répertoire « META-INF ». Essentiellement, ce court fichier XML localise, dans l'arborescence interne, un autre fichier XML, lui aussi indispensable et dont l'extension est « .opf » (pour *Open Packaging Format*). Ligne de l'élément <rootfile> de « container.xml » : <rootfile full-path="OEBPS/content.opf" media-type="application/oebps-package+xml"/>.

Les « documents de contenu » d'EPUB 3 sont des fichiers XHTML. À ce titre, ils doivent se conformer aux syntaxes HTML et XML, et peuvent intégrer des langages XML spécifiques : MathML pour la gestion des équations mathématiques, par exemple, ou SVG (images vectorielles).

**CSS** : relier les fichiers XHTML à une ou des feuilles de style CSS n'est pas une obligation, mais une recommandation fonctionnelle.

### Versions

Avec le passage de la version 2 à la version 3, en octobre 2011, les capacités techniques du format augmentent fortement. L'éventail des exigences éditoriales auxquelles il peut répondre s'élargit.

- Le support d'HTML 5 rend possible le codage d'une accessibilité native complète, et l'intégration de contenus audio et vidéo.

- La synchronisation audio/texte (*Media Overlays*) est un outil supplémentaire pour l'accessibilité native.

- Le support de CSS 3 améliore la gestion des flux textuels et permet la prise en charge des écritures idéogrammatiques, verticales ou de droite à gauche (arabe et hébreu par exemple) : le format s'internationalise.

- Le support de JavaScript permet le codage d'une interactivité contenus/lecteur.

La gestion des magazines, des publications scolaires, professionnelles et scientifiques reste certes encore délicate, mais EPUB 3 propose des solutions : notamment une exception au principe d'adaptabilité des contenus en permettant, lorsqu'une nécessité éditoriale l'impose, de figer les pages de la publication : on parle alors de *fixed-layout*.

**Au-delà de la version 3.2** : le W3C semble satisfait de la maturité du format dans sa version actuelle, et en fait la promotion, notamment dans l'objectif d'augmenter sa représentation dans la production éditoriale (au détriment d'EPUB 2.0.1, donc).

Un format parallèle, **WEB PUBLICATION**, est cependant à l'étude, qui ferait le lien entre publication packagée offline et disponibilité sur le web. Le format est actuellement présenté comme « une collection de ressources, »
<figure><img src="image_71.png" /></figure>

organisées ensemble par le biais d'un manifeste avec un ordre de lecture par défaut, [...] identifiable de façon unique et pouvant être présentée à l'aide des technologies *Open Web Platform* ».

## Contenu

On trouvera une description de l'anatomie de l'EPUB 3 à l'adresse suivante.

EPUB 3 peut intégrer les formats suivants (W3C core media types) :

- Images : GIF, JPEG, PNG, SVG ;

- Audio : MPEG-1/2 layer III, AAC ;

- Vidéo : H.264 ;

- Polices : TTF, OTF, WOFF, WOFF2.

Il est à noter qu'EPUB 3 laisse la porte ouverte à l'intégration d'autres formats, à la condition du signalement explicite dans le fichier « .opf » des formats de remplacement en cas de non prise en charge par le système de lecture (mécanisme du manifest fallback).

## Organisme de maintenance et documentation de référence

Jusqu'en février 2017, c'est l'IDPF (International Digital Publishing Forum) qui maintient et promeut le format. Relais est passé depuis au W3C, avec qui l'IDPF a fusionné à cette date. Le document EPUB 3.2 W3C Community Group Final Report est une bonne porte d'entrée vers la très riche documentation du W3C.

Certaines versions d'EPUB ont également été portées par l'IDPF à l'ISO ; ainsi les spécifications d'EPUB 3.0 ont été publiées sous l'identifiant ISO/IEC TS 30135, et celles d'EPUB 3.0.1 sous l'identifiant ISO/IEC 23736. Une norme ISO sur l'accessibilité des EPUB est également à l'étude : ISO/IEC_DIS 23761. Des spécifications techniques doivent compléter le paysage normatif autour d'EPUB : l'ISO/IEC TS 22424 définit une restriction du format EPUB pour sa préservation à long terme et son empaquetage avec des métadonnées METS et PREMIS, et l'ISO/IEC CD TS 23078 spécifie une technologie standard de DRM.

On pourra aussi consulter :

- une évaluation par la British Library de tous les formats ebook ;

- une évaluation par la British Library du format EPUB ;

## Identifiants

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Bibliothèque du Congrès</td><td>fdd000310 (famille EPUB), fdd000278 (EPUB 2), fdd000308 (EPUB 3.0), fdd000311 (EPUB 3.0.1), fdd000309 (EPUB 3.2), fdd000519 (restriction d'EPUB pour la préservation)</td></tr><tr><td>Wikidata</td><td>Q475488</td></tr><tr><td>PRONOM</td><td>fmt/483</td></tr><tr><td>Just Solve the File Format Problem</td><td>EPUB</td></tr></tbody></table>

## Caractéristiques techniques

Une publication EPUB peut être tatouée numériquement afin d'être rendue traçable, ou verrouillée par un DRM. Deux principaux systèmes de protection sont utilisés sur les EPUB : le verrou ACS4, développé par Adobe et qui consiste en un **chiffrement complet** du livre opéré à la volée au moment du téléchargement depuis un site web (CPO-PRO) ; et le verrou LCP (Licensed Content Protection), développé par EDRLab, plus flexible. Si le verrou ACS4 d'Adobe a fait l'objet d'une adoption massive par les éditeurs français dès 2010, le consensus s'est inversé ces dernières années, et ACS4 cristallise aujourd'hui les reproches de nombreux acteurs de la chaîne du livre numérique, libraires et bibliothèques notamment : parcours de premier achat complexe, problèmes techniques liés au chiffrement, centralisation des données personnelles des usagers, coût transactionnel et coût unitaire élevés, incompatibilité avec l'accessibilité des contenus...
<figure><img src="image_72.png" /></figure>

Plus souple, moins cher, compatible avec l'accessibilité des contenus, LCP est, aux yeux du monde éditorial aujourd'hui, une bonne alternative. Métadonnées internes

C'est le fichier OPF (voir *supra* : « Relations à d'autres formats ») qui centralise les métadonnées (Dublin Core et Schema.org) dans sa première section <metadata>. La deuxième - <manifest> - détaille les ressources de la publication. La troisième - <spine> - fixe l'ordre de lecture des chapitres XHTML.

Outils connus par la BnF

Il serait vain ici de vouloir lister les gestionnaires de bibliothèques ou les lecteurs d'EPUB.

Méritent, à notre sens, d'être signalés :

- **InDesign**, comme logiciel PAO exportant le format ;

- **Sigil**, comme éditeur *open source*, permettant la correction ou la création *ex nihilo* du format ;

- **Thorium**, comme lecteur pour Windows 10, MacOS et Linux, développé par EDRLab.

Par ailleurs, il existe un outil officiel de validation - **EPUBCheck** - aujourd'hui dans sa version 4.2.5. Exécutable en ligne de commande ou utilisable comme une bibliothèque Java, il vérifie la conformité d'un fichier aux spécifications du format, dont il prend en charge les versions 2 et 3. L'outil réalise également une caractérisation qui produit nativement un rapport au format XMP.

On peut lui adjoindre un autre outil de vérification, spécifiquement du codage de l'accessibilité : **Ace**, développé par le DAISY Consortium.

Usage ou présence dans les collections de la BnF

Plusieurs milliers de documents patrimoniaux sont disponibles aux formats EPUB 2 et 3 dans la bibliothèque numérique de la BnF, **Gallica**.

Le Référentiel ePub 3 présente les attentes de la BnF en matière de production de livres électroniques au format EPUB. Il détaille notamment les modalités de conversion des contenus patrimoniaux de la bibliothèque vers ce format.

Dans le cadre de la loi relative au droit d'auteur et droits voisins dans la société de l'information dite **Loi DADVSI**, la BnF a pour mission de collecter, conserver et donner accès à tous les livres numériques au format EPUB diffusés au public par voie électronique en France. Ainsi, les livres numériques au format EPUB qui sont téléchargeables librement en ligne font l'objet d'une collecte automatique par moissonnage grâce à un robot-crawler, dans le cadre du dépôt légal du web. Les EPUB collectés de cette manière sont consultables grâce à l'application Archives de l'internet uniquement dans les salles de recherche de la BnF et les bibliothèques de dépôt légal imprimeur en région.

Cependant, la majorité des ouvrages au format EPUB mis à disposition du public dans le circuit commercial n'étant pas librement téléchargeables, le dépôt légal de ces livres numériques nécessite la mise en place d'un circuit spécifique, qui implique un dépôt de leurs publications à la BnF par les déposants. Ainsi, les livres numériques au format EPUB sans mesure technique de protection (*Digital Rights management*) collectés par dépôt des éditeurs sont accessibles grâce à l'application Gallica Intra Muros uniquement dans les salles de recherche de la BnF.

Le dispositif PLATON (PLAteforme de Transfert d'Ouvrages Numériques) accueille les fichiers source des éditeurs (11% au format EPUB, soit 6 000 fichiers en 2020) et les adaptations réalisées par les organismes transcripteurs (0,5% au format EPUB, soit 38 fichiers) dans le cadre de l'exception handicap au droit d'auteur. Les fichiers source des éditeurs sont accessibles par les organismes transcripteurs agréés via PLATON. Les adaptations sont destinées aux personnes empêchées de lire.
<figure><img src="image_73.png" /></figure>

## Identifiants

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q579857</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000341 (codec)<br/>fdd000349 (combo AVI + FFV1)<br/>fdd000343 (combo MKV + FFV1)</td></tr><tr><td>Just Solve the File Format Problem</td><td>FFV1</td></tr></tbody></table>

## Caractéristiques techniques

### Robustesse

Depuis sa version 2, FFV1 permet d'associer à chaque pavé (slice) une empreinte CRC-32. Ce mécanisme d'empreinte numérique interne renforce sa **résilience (CPC-ROB)**. Lors de l'encodage avec l'outil `ffmpeg`, il est nécessaire de spécifier l'option `-slicecrc 1` pour activer ce mécanisme dans le fichier produit.

Le nombre de pavés par image est paramétrable, et va de 4 à 1023 (une liste des valeurs autorisées est disponible sur le site reto.ch).

A noter que plus le découpage est important et plus l'encodeur (et le décodeur) utilisera des ressources machine et le temps de codage / décodage sera important.

### Compacité

La compression FFV1 permet d'obtenir un poids variant entre 45 % et 55 % par rapport au même flux non compressé.

L'algorithme de compression FFV1 est **intra-trame**, (la compression est interne à chaque image, à l'inverse de la compression inter-trames, qui élimine la redondance sur une succession d'images). Cela rend le format adapté à la post-production. En outre, cela permet d'éviter la propagation des erreurs de compression d'une image à une autre. Il est relativement simple (CPO-SIM), comparé notamment à l'algorithme JPEG 2000 sans perte, donc plus rapide que lui et avec un ratio de compression légèrement supérieur (CPO-COM). Le ratio de compression entre le format de flux vidéo V210 et FFV1 est approximativement de 65% (le débit de FFV1 étant variable, cette valeur peut différer selon le contenu des images).

Chaque image (frame) du flux FFV1 est découpé en pavés (slices) qui peuvent disposer chacune d'une empreinte CRC-32 (CPO-ROB). Ce découpage permet également le multi-threading, donc l'accélération des processus d'encodage et décodage si le matériel le permet.

<table><thead><tr><th></th><th></th><th>Résolution SD (720 x 576)</th><th>Résolution HD (1920 x 1080)</th></tr></thead><tbody><tr><td></td><td>Cadence / Espace colorimétrique</td><td>Poids estimé pour 1 heure</td><td>Poids estimé pour 1 heure</td></tr><tr><td>FFV1 10 bits</td><td>25i 422</td><td>42 Go</td><td>140.6 Go</td></tr><tr><td>FFV1 8 bits</td><td>25i 420</td><td>28 Go</td><td>82.3 Go</td></tr></tbody></table>

Pour un usage de préservation à long terme, le wiki `ffmpeg` recommande de faire la compression en deux passes : la première vise à réunir de l'information en vue d'obtenir un taux de compression optimal lors de la seconde - cela au prix, bien sûr, d'un temps d'encodage plus important.

## Outils connus par la BnF

- **Lecture** : des logiciels de lecture libres et/ou gratuits grand public lisent FFV1, notamment VLC et Windows Media Player. L'outil `ffplay`, associé à `ffmpeg`, est capable de lire de très nombreux types de fichiers audio et vidéo, parmi lesquels FFV1. Pour une implémentation au sein de systèmes informatiques, on peut également signaler un décodeur en Go.

- **Production** : `ffmpeg` est évidemment l'outil principal pour des transformations vers ou depuis FFV1. Le site `ffmprovisr` propose des lignes de commande types pour transcoder vers FFV1. La société MediaArea,
<figure><img src="image_74.png" /></figure>

sponsorisée par de nombreuses institutions de conservation internationales, a développé l'outil
RAWcooked qui permet de convertir un flux vidéo brut (une séquence d'images en TIFF ou DPX) vers
un fichier MKV FFV1 FLAC. (Cette transformation est intégralement réversible.)

- Édition / transformation : ffmpeg est également l'outil à utiliser pour produire des dérivés destinés à différents usages, de consultation notamment. On notera que réaliser des opérations de post-production nécessite une transformation vers un codec adapté à l'édition (par exemple, ProRes).

- Caractérisation : l'outil d'analyse et d'extraction de métadonnées techniques pour la BnF est MediaInfo, qui dispose d'une sortie native dans le format de métadonnées de caractérisation préféré par la BnF, MPEG-7. L'outil ffprobe, associé à ffmpeg, est une alternative également utile.

- Vérification de conformité à un profil d'application : le logiciel MediaConch de MediaArea permet de vérifier que les fichiers MKV FFV1 correspondent à un profil d'application défini par une institution. Ce logiciel dispose d'une interface en ligne de commande et d'une interface graphique.

## Usage ou présence dans les collections de la BnF

Le FFV1 est utilisé pour la numérisation des bandes EIAJ et 1 Pouce B, C et IVC conservées à la BnF. En effet, leur fragilité et la rareté de leur matériel de lecture incitent la BnF à choisir un format et une qualité à même de durer dans le temps sans demander une renumérisation, y compris pour les besoins de post-production. Son paramétrage est décrit dans le référentiel de format vidéo.
<figure><img src="image_75.png" /></figure>

## 4.12. GeoJP2

### Description

GeoJP2 ou GeoTIFF in JPEG 2000 est un format cartographique ouvert de métadonnées géographiques embarquées dans un fichier JPEG 2000. Il a d'abord été développé comme format fermé par Mapping Science en 2003. Mapping Science a été racheté par LizardTech qui a publié une version ouverte du format en 2004 (CPO-DOC). LizardTech a ensuite fusionné avec Extensis en 2018. GeoJP2 en est la propriété et une marque déposée (CPO-LIB).

Le format utilise les tags du GeoTIFF pour établir un géoréférencement interne à l'image JP2. Il hérite de l'efficacité du GeoTIFF pour le géoréférencement simple (tous les systèmes de référence du répertoire EPSG) mais n'est comme lui pas adapté pour représenter des relations spatiales complexes comme les cubes 3D, les mosaïques d'images ou les séries temporelles. L'intégration additionnelle d'un World File d'Esri est optionnelle (CPS-EXP).

GeoJP2 ne doit pas être confondu avec GMLJP2 (ou GML in JPEG 2000), le mécanisme de géoréférencement interne concurrent pour JPEG 2000, standardisé par l'Open Geospatial Consortium. Par parallélisme, GeoJP2 est parfois désigné sous l'appellation explicite de « GeoTIFF in JPEG 2000 ». Les rédacteurs de la spécification de 2004 (LizardTech) proposent une alternative proche en titre (« The "GeoTIFF Box" Specification for JPEG 2000 Metadata ») pour éviter d'utiliser GeoJP2, qui est une marque déposée, et faciliter la diffusion du format.

Enfin, GeoJP2 est aussi parfois nommé GeoJPEG2000 par développement du sigle. Cependant, le seul nom officiel du format est GeoJP2 et l'usage de GeoJPEG2000 présente le risque d'évoquer tout fichier JPEG 2000 géoréférencé, quelle que soit la méthode (par exemple un World file dans le sondage OPF sur les formats de préservation).

Pour la préservation, GeoJP2 présente le handicap d'être un standard de fait concurrencé par un standard OGC visant la même fonction (GMLJP2). Son avantage est d'être simple, de reposer sur des formats dont les standards sont eux stables et d'être potentiellement plus compact que des formats non basés sur JPEG 2000 comme GeoTIFF.

### Sociabilité

JPEG2000 est couramment proposé au côté de TIFF pour la diffusion des images de télédétection, par exemple par Ordnance survey, Airbus intelligence ou TerraMetrics alors que TIFF domine pour les cartes statiques. Le géoréférencement GeoJP2 se rencontre par conséquent sur ce premier segment documentaire.

L'IGN français utilise GeoJP2 pour diffuser ses orthophotographies. GeoJP2 est également un des formats recommandés en 2023 par le rapport du groupe de travail des Nations Unies pour la diffusion des orthoimages. GeoJP2 est le format d'archivage de l'imagerie à l'IGN. Il est un des deux formats de diffusion des cartes statiques à l'IGN (CPO-SOC).

Enfin le GeoJP2 est pris en charge par les systèmes d'information géographique dominant le marché, QGIS et ARCGIS. La bibliothèque GDAL permet de le lire (CPO-OUT).

### Relations à d'autres formats

Le format est une spécialisation du format JPEG 2000 s'appuyant sur le format GeoTIFF 1.0 et le format World File d'ESRI.

Pour le géoréférencement interne du JPEG 2000, le format a pour concurrent GMLJP2, qui utilise le GML et non le GeoTIFF à cette fin.

### Versions

La version 0.0 (appel à commentaires) des spécifications de LizardTech de 2004, la seule disponible pour les producteurs, est de fait en vigueur.

### Contenu

GeoJP2 consiste à inclure obligatoirement un fichier GeoTIFF dégénéré dans une boîte de type "UUID" autorisé par le format JP2. Comme GeoTIFF il utilise uniquement six tags TIFF pour enregistrer l'information géographique : 33550, 34264, 33922, 34735, 34736, et 34737.

Un World File Esri peut théoriquement être placé dans une autre boîte mais son expressivité est inférieure au GeoTIFF, rendant son usage peu attractif.
<figure><img src="image_76.png" /></figure>

## Organisme de maintenance et documentation de référence

GeoJP2 ne dispose plus de site officiel depuis que LizardTech a été intégré dans Extensis, société qui ne propose aucune ressource sur le format. La spécification 0.0 qui sert de référence aux producteurs est archivée sur Internet Archive.

Les spécifications ne sont plus maintenues par un organisme actif mais celles du GeoTIFF relèvent d'un standard de l'OGC et celles du JPEG 2000 de l'ISO. Le World file d'Esri est lui un format très simple et ouvert. Par ailleurs, un producteur de référence, l'IGN, documente son usage du format. (CPO-STA, CPO-DOC).

## Identifiants

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q28757848</td></tr><tr><td>Just Solve the File Format Problem</td><td>GeoJP2</td></tr></tbody></table>

## Caractéristiques techniques

Le format est simple à mettre en œuvre en utilisant la structure du GeoTIFF qui est un des formats d'images géoréférencées les plus répandus (CPO-SIM). Il добироспектаe des capacités de compression de JPEG 2000 et de sa robustesse (CPO-COM, CPO-ROB).

## Métadonnées internes

Les métadonnées géographiques fournies par le GeoTIFF sont très expressives pour un géoréférencement simple. Cependant le format n'est pas adapté pour décrire des relations spatiales plus complexes (mosaïques, 3D au delà de l'altitude).

## Outils connus par la BnF

- **Caractérisation** : GDAL avec la commande `gdalinfo`.

- **Validation** : une conversion dans GDAL du fichier peut indiquer des erreurs dans sa formation. FME est une solution payante de validation des formats géographiques.

- **Édition** : l'édition et la production de fichiers GeoJP2 est faite à partir de systèmes d'information géographique. La bibliothèque open source GDAL gère également l'ensemble des formats matriciels ou vectoriels géographiques, dont GeoJP2.

## Usage ou présence dans les collections de la BnF

La BnF reçoit par dépôt légal la collection d'orthophotographies RVB et infrarouge couleur de l'Institut national de l'Information géographique et forestière (IGN) au format GeoJP2 avec un taux de compression nominal 20 (éditions postérieures à 2015).
<figure><img src="image_77.png" /></figure>

## 4.13. GeoPackage (GPKG)

### Description

GeoPackage, OGC GeoPackage ou GPKG est un format cartographique de données vectorielles et maillées, fondé sur SQLite et créé en 2014. Il est maintenu et standardisé par l'Open geospatial consortium (OGC) qui publie ses spécifications. (CPO-LIB, CPO-DOC, CPO-STA).

GeoPackage se prête à la constitution de plusieurs types de documents cartographiques numériques. Il permet, avec ses extensions, l'encodage direct de bases de données géographiques vectorielles, de bases de statistiques géographiques et la conteneurisation de collections d'images et de grilles (à bande unique) matricielles. GeoPackage a été conçu pour dépasser les limitations en polyvalence, performances, expressivité, compacité ou robustesse des formats existants, notamment le Shapefile (CPS-EXP).

Pour la préservation GeoPackage présente de bonnes performances sur tous les critères définis par la BnF. Il a déjà été adopté par des institutions de référence (LoC, NARA). Ses seuls handicaps sont une adoption par les producteurs qui reste à confirmer et une transparence moindre que les formats textuels.

### Sociabilité

Le format GeoPackage est d'un usage croissant pour la diffusion des bases de données géographiques vectorielles. Des agences nationales de cartographie comme l'IGN française, Ordnance Survey ou l'OFTS (SwissTopo) l'ont adopté parmi les formats de diffusion de leur base de donnée topographique de référence. L'USGS l'utilise pour diverses bases topographiques. Le site Geofabrik propose désormais ses imports d'OpenStreetMap en Geopackage.

En préservation numérique, le format est le seul qui soit préféré par la Bibliothèque du Congrès pour toutes ses catégories de données. Il figure également parmi les formats géographiques préférés par les Archives nationales des Etats-Unis (CPO-SOC).

Le format est pris en charge par les principaux Systèmes d'information géographique, notamment QGIS et ARCGIS. Il est lu par la bibliothèque GDAL (CPO-OUT).

### Relations à d'autres formats

GeoPackage est fondé sur la version 3 de la base de données SQLite qui propose des fichiers de bases de données indépendants de leur environnement d'exploitation.

GeoPackage peut contenir des tuiles images PNG, JPEG et WebP ainsi que des grilles dans une version restreinte de TIFF.

L'extension officielle Related tables permet d'inclure dans les GPKG des fichiers multimédia dont le type MIME appartient au répertoire IANA. Les spécifications visent principalement l'adjonction de photographies, sons, vidéos et PDF, par exemple l'image d'un bâtiment lié à l'objet cartographique correspondant dans la base de données.

Les fichiers GeoPDF peuvent contenir des GPKG.

### Versions

La dernière version est la version 1.4 de 2024. Toutes les versions des spécifications sont disponibles sur le site du GeoPackage vers lequel renvoient les liens du site de l'OGC.

### Contenu

#### Tables

Deux tables sont obligatoires :

- **gpkg_spatial_ref_sys**: renseigne sur les systèmes de référence (CRS) utilisés dans les données. Ils doivent être définis en WKT (Well-Known Text) et une entrée doit obligatoirement porter sur WGS-84, même si les données n'utilisent pas ce système.

- **gpkg_contents**: index décrivant les tables de données du fichier GeoPackage. Il indique le nom des tables, leur type de données, les coordonnées de leur rectangle englobant, leur date de dernière modification et leur système de référence.

#### Types de contenus

Deux types de contenus cartographiques sont possibles dans un GeoPackage standard :
<figure><img src="image_78.png" /></figure>

- Les données géographiques vectorielles : des tables attributaires stockent la sémantique et la géométrie des objets. Un index des géométries de ces tables figure dans une table obligatoire `gpkg_geometry_columns`.

- Les collections d'images matricielles : les deux formats acceptés sont le PNG et le JPEG. Les fichiers images élémentaires sont nommés "tuiles", ils forment des "matrices", éventuellement pyramidales, organisées par la table `gpkg_tile_matrix_set`.

GeoPackage peut aussi contenir des données attributaires, non cartographiques (bases de statistiques géographiques) : tables de données sans géométrie explicitement décrite mais revoyant à un système de référence indirect (adresses, codes etc).

## Extensions

Des « extensions » permettent d'exploiter des fonctions supplémentaires. Les extensions approuvées par l'OGC figurent dans les spécifications. Une table `gpkg_extensions` répertorie les extensions utilisées par un fichier `GPKG`. Les extensions OGC permettent :

- l'utilisation de géométries complexes additionnelles,

- l'utilisation d'index spatiaux R-tree pour améliorer les recherches dans les tables comportant plusieurs milliers de lignes,

- la création de niveaux de zooms non compris dans la norme principale,

- l'utilisation de tuiles au format WebP,

- l'ajout d'une table de métadonnées riches (stockage des styles, généalogie des données, modèle et schéma de données),

- l'ajout d'un schéma détaillé des tables allant au delà des possibilités permises par SQLite pour décrire sa structure,

- l'utilisation du standard OGC pour Well known text de 2019 pour les systèmes de référence,

- la création de bases de données géographiques matricielles à bande unique, pour stocker des grilles régulières, en particulier les modèles d'élévation, dans les formats `TIFF` (limité) et `PNG`,

- l'intégration au fichier GeoPackage (dans un `BLOB`, `Binary Large Object`) de fichiers multimédia additionnels liés aux informations géographiques du `GPKG`.

Les développeurs peuvent créer d'autres extensions pour GeoPackage qui ne portent pas l'extension `.gpkg`. Le site officiel du GeoPackage les répertorie. Elles permettent notamment de stocker des tuiles vectorielles et de la symbologie.

## Organisme de maintenance et documentation de référence

Les spécifications sont maintenues par l'OGC. Tous les états sont disponibles sur le site du GeoPackage qui est archivé (les liens dans les spécifications vers des annexes hébergées sur le site de l'OGC renvoient aussi à des pages archivées).

## Identifiants

Extension(s) : `.gpkg`

Type(s) MIME : `application/geopackage+sqlite3`

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q22908624</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000520</td></tr><tr><td>PRONOM</td><td>fmt/1700</td></tr><tr><td>Just Solve the File Format Problem</td><td>GeoPackage</td></tr></tbody></table>

## Caractéristiques techniques

GeoPackage est un format compact pour des jeux de données vectoriels dépassant plusieurs Mo. Dans ce rôle il surpasse largement le Shapefile (CPO-COM).

GeoPackage est un format binaire mais il se fonde sur SQLite pour lequel les outils sont répandus et est pris en charge par les SIG (CPO-TRA). Sa structure en un fichier unique permet de manipuler ou transférer simplement
<figure><img src="image_79.png" /></figure>

des données souvent éclatées en une multitude de fichiers dans d'autres formats (SHP, collections de rasters) (CPO-SIM).

GeoPackage est autonome grâce à ses possibilités d'autodocumentation et le mécanisme des extensions qui évite de recourir à des fichiers externes pour faire face à de nouveaux besoins (CPO-AUT).

GeoPackage ne dispose pas de fonctionnalité native pour protéger les données (CPO-PRO).

GeoPackage est robuste. Le format a été conçu pour être utilisé dans des environnement où la connectivité est dégradée. Il impose deux tests d'intégrité qui ne sont qu'optionnels pour les bases SQLite. De plus le format applique la norme ISO *Well-Known Binary* en ajoutant une fonction d'encodage des ensembles de points vides qui évite leur mauvaise interprétation (CPO-ROB).

## Métadonnées internes

Trois tables optionnelles du GPKG permettent préciser ou documenter les données :

- La table `gpkg_data_columns`: permet de décrire des colonnes spécifiques dans une table `GeoPackage` (nom, description, contraintes).

- La table `gpkg_metadata`: permet de stocker des métadonnées dans des formats compatibles avec des types MIME (text/xml par défaut) qui peuvent suivre n'importe quel schéma de métadonnées standardisé comme ISO 19115 et Dublin Core ou encore des schémas UML et GML.

Son utilisation requiert obligatoirement une table `gpkg_metadata_reference` qui associe les métadonnées stockées dans `gpkg_metadata` aux données géographiques du fichier. Les deux tables permettent de mettre en œuvre le modèle hiérarchique de métadonnées de la norme ISO 19115.

## Outils connus par la BnF

- **Caractérisation**: OGR, les outils SQLite (comme DB Browser for SQLite), QGIS et le logiciel payant FME.

- **Validation**: le PDAOK (géoportail néerlandais) a développé un [GeoPackage validator](https://www.gcpadok.org/) qui peut s'adapter aux exigences d'autres organisations.

- **Édition**: l'édition et la production de fichiers GeoPackage est faite à partir de systèmes d'information géographique ou d'outils SQLite. La bibliothèque open source GDAL gère également l'ensemble des formats matriciels ou vectoriels géographiques, dont GPKG.

## Usage ou présence dans les collections de la BnF

La BnF envisage de recevoir les bases de données géographiques vectorielles issues du dépôt légal au format GeoPackage.
<figure><img src="image_80.png" /></figure>

## 4.14. GeoTIFF

### Description

GeoTIFF est un format cartographique standardisé et ouvert (CPO-LIB) de métadonnées géographiques embarquées dans un fichier TIFF 6.0 conforme.

Développé au début des années 1990, sa version stabilisée date de 1995. Il est devenu un standard de l'Open Geospatial Consortium (OGC) en 2019 (CPO-STA, CPO-DOC). Il tire parti du caractère ouvert et extensible du format TIFF sur lequel il est fondé.

Le format GeoTIFF est utilisé pour constituer des documents cartographiques de types distincts. D'une part, des images, nativement numériques (cartes statiques) et issues de la télédétection (notamment orthophotographies). D'autre part, des bases de données géographiques, pour représenter les phénomènes continus en topographie (modèles d'élévation), sciences de la terre, de l'environnement, économie, sciences sociales et démographie. Il peut encoder leurs valeurs colorimétriques (images) ou sémantiques (bases de données) sur plusieurs bandes. (CPS-EXP)

Pour la préservation GeoTIFF propose de bonnes performances sur tous les critères dégagés par la BnF. Néanmoins, suivant les catégories documentaires, des considérations de volumétrie peuvent conduire à lui préférer d'autres formats comme JPEG 2000 géoréférencé.

### Sociabilité

Le GeoTIFF est un format de publication très répandu parmi les agences nationales de cartographie pour les cartes statiques (IGN et SHOM en France, BGK, USGS). Pour la diffusion des orthophotographies, l'IGN espagnole, Ordnance Survey et l'OFTS utilisent un sous-type du GeoTIFF, le *Cloud optimized GeoTIFF*. L'IGN a annoncé en 2024 que GeoTIFF serait employé pour diffuser ses modèles d'élévation issus du LIDAR. Il est déjà utilisé par le BKG et l'USGS à cette fin. GeoTIFF est également le support de nombreuses bases thématiques, comme celle de la *démographie européenne*, ou de l'occupation des sols *Corine Land Cover*.

GeoTIFF est le format choisi par l'IGN pour l'archivage de ses cartes statiques. Il est également le seul format matriciel cartographique à bénéficier d'un large consensus dans la communauté de préservation comme le montre un *sondage international de l'OPF (2023)*. Il est le seul format préféré par la LoC pour tous les documents matriciels géoréférencés. Cependant, compte tenu des nombreux usages documentaires du GeoTIFF, cette préférence pour le format n'indique pas les cas précis dans lesquels les institutions concernées le plébiscitent. (CPO-SOC)

Enfin le GeoTIFF est pris en charge par les systèmes d'information géographique dominant le marché, QGIS et ARCGIS. La bibliothèque GDAL permet de le lire (CPO-OUT).

### Relations à d'autres formats

Le format est une spécialisation du format TIFF 6.0.

Le format possède un sous-type, *Cloud Optimized GeoTIFF (COG)*, destiné au stockage sur un serveur web : il permet de ne consulter que les données du fichier demandées par des requêtes HTTP, au lieu de le décharger dans son entier.

Le format est utilisé dans le format *GeoJP2* pour géoréférencer un fichier JPEG 2000.

Une extension du format *GeoPackage* permet d'y intégrer des fichiers TIFF limités à une bande pour former des bases matricielles (notamment des MNT).

### Versions

Sa dernière version 1.1 a été publiée en 2019 par l'OGC. Cependant, elle n'apporte que des modifications mineures par rapport à la version 1.0 de 2000. Il s'agit de permettre l'utilisation des systèmes de référence qui ont été inclus dans le registre EPSG qui datait de la mise en forme de la version 1.0 en 1995. La norme GeoTIFF de l'OGC est donc rétrocompatible avec la version 1.0.

### Contenu

GeoTIFF utilise uniquement six tags TIFF pour enregistrer l'information géographique : `33550`, `34264`, `33922`, `34735`, `34736`, et `34737`. Le tag 3735, « GeoKeyDirectoryTag », contient des « Geokeys » qui permettent de décrire les informations de projection avec un niveau d'abstraction supplémentaire par rapport à un tag TIFF.

### Tags géographiques du GeoTIFF
<figure><img src="image_81.png" /></figure>

<table><thead><tr><td>Nom du tag géographique</td><td>Numéro</td><td>Description</td></tr></thead><tbody><tr><td>ModelPixelScaleTag</td><td>33550</td><td>Taille des pixels en degrés si coordonnées géographiques ou mètres/pieds si projection.</td></tr><tr><td>ModelTiePointTag</td><td>33922</td><td>Correspondance entre un pixel de l'image et ses coordonnées géographiques ou projetées.</td></tr><tr><td>ModelTransformationTag</td><td>34264</td><td>Matrice de transformation complète pour des transformations complexes que les deux premiers tags ne gèrent pas.</td></tr><tr><td>GeoKeyDirectoryTag</td><td>34735</td><td>Paramètres descriptifs de l'image et de sa localisation, contient les GeoKeys.</td></tr><tr><td>GeoDoubleParamsTag</td><td>34736</td><td>Stocke des valeurs numériques de haute précision (double) nécessaires pour certaines GeoKeys.</td></tr><tr><td>GeoInternParamsTag</td><td>34737</td><td>Permet de décrire des valeurs de métadonnées textuelles comme des descriptions de systèmes ou des noms d'unités.</td></tr></tbody></table>

## Clés géographiques du tag GeoKeyDirectoryTag

<table><thead><tr><td>Nom de la GeoKey</td><td>Numéro</td><td>Description</td></tr></thead><tbody><tr><td>GTModelTypeGeoKey</td><td>1024</td><td>Type du système de coordonnées (projeté ou non).</td></tr><tr><td>GTRasterTypeGeoKey</td><td>1025</td><td>Définit si les pixels sont référencés par leur centre ou leur coin supérieur gauche.</td></tr><tr><td>GTCitationGeoKey</td><td>1026</td><td>Libellé textuel explicite relatif à l'ensemble du système de coordonnées.</td></tr><tr><td>GeographicTypeGeoKey</td><td>2048</td><td>Code du système géodésique EPSG</td></tr><tr><td>GeogCitationGeoKey</td><td>2049</td><td>Libellé textuel relatif au système géodésique (datum, ellipsoïde).</td></tr><tr><td>GeogAngularUnitsGeoKey</td><td>2054</td><td>Unité angulaire utilisée (degré, radian, etc.).</td></tr><tr><td>ProjectedCSTypeGeoKey</td><td>3072</td><td>Code EPSG décrivant le système de coordonnées projetées.</td></tr><tr><td>PCSCitationGeoKey</td><td>3073</td><td>Libellé textuel relatif au système de coordonnées projetées.</td></tr><tr><td>ProjLinearUnitsGeoKey</td><td>3076</td><td>Unité linéaire utilisée (mètre, pied, etc.).</td></tr></tbody></table>

(Tableaux adaptés de la description des tags et clés utilisés par l'IGN pour GeoJP2, complétés par la spec 1.0 du GeoTIFF).

Comme TIFF, GeoTIFF est extensible et peut donc contenir des extensions ou des IFD propriétaires. Cette pratique est néanmoins déconseillée par la spécification elle-même.

## Organisme de maintenance et documentation de référence

Le standard GeoTIFF dispose d'un site officiel. Le format est maintenu par l'Open Geospatial Consortium qui publie sa spécification. La version 1.0 est aussi archivée.

## Identifiants

Extensions: .tif, .tiff

Type MIME: image/tiff

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q1502796</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000279</td></tr></tbody></table>
<figure><img src="image_82.png" /></figure>

<table><tr><td>PRONOM</td><td><a href="#">fmt/155</a> L'entrée est signalée comme peu détaillée.</td></tr><tr><td>Just Solve the File Format Problem</td><td><a href="#">GeoTIFF</a></td></tr></table>

## Caractéristiques techniques

Le GeoTIFF permet la compression sans perte, notamment par l'algorithmme Lempel-Ziv-Welch (LZW), souvent utilisé par les agences nationales de cartographie. Avec compression il atteint des volumes proches du JPEG 2000 standard qui peut lui même être encore optimisé, voir pages 5-9 du document de l'IGN sur le JPEG 2000 (CPO-COM).

Le GeoTIFF est simple. Il s'appuie sur la structure de TIFF et le géoréférencement repose sur des tags peu nombreux. Cependant l'usage d'une compression peut affecter cette simplicité (CPO-SIM).

Le GeoTIFF est robuste. La structure en tags le rend robuste face à des erreurs locales. Les données sont préservées par les compressions sans perte (CPO-ROB).

Le format GeoTIFF n'intègre pas de mécanismes de protection (CPO-PRO).

Même s'il s'agit d'un format binaire, GeoTIFF est supporté par beaucoup d'outils capables de donner accès à sa structure. Tout lecteur d'image TIFF peut donner accès au seul contenu graphique (CPO-TRA).

La bibliothèque logicielle GDAL citée plus bas publie un corpus d'exemples de fichiers GeoTIFF.

## Outils connus par la BnF

### Caractérisation

- Le module TIFF de JHOVE liste l'ensemble des tags GeoTIFF présents dans le fichier.

- GDAL avec la commande `gdalinfo`.

### Validation

- Le module TIFF de JHOVE reconnaît la présence des tags GeoTIFF et l'identifie comme un profil de TIFF. Note : on relève des bogues lors de la validation de certains fichiers GeoTIFF avec les versions de JHOVE antérieures à 1.24.

- Une conversion dans GDAL du fichier peut indiquer des erreurs de structure.

- FME est une solution payante de validation des formats géographiques.

### Édition

- L'édition et la production de fichiers GeoTIFF est faite à partir de systèmes d'information géographique.

- La bibliothèque logicielle open source libgeotiff, bâtie sur libtiff, permet de lire et d'écrire des tags GeoTIFF dans les fichiers TIFF.

- La bibliothèque open source GDAL gère également l'ensemble des formats matriciels ou vectoriels géographiques, dont GeoTIFF.

- Enfin, à partir de sa version 2.10.24, nommée « version cartographe », le logiciel libre GIMP est capable d'importer les tags TIFF spécifiés par GeoTIFF.

## Usage ou présence dans les collections de la BnF

Depuis 2024, la BnF conserve une collection d'images cartographiques en GeoTIFF, le Plan IGN, issue du dépôt légal.
<figure><img src="image_83.png" /></figure>

## 4.15. H.264 (codec)

### Description

H.264, également nommé « MPEG-4 AVC » (Advanced Video Coding), ou « MPEG-4 Part 10 » est un codec normalisé de compression vidéo avec perte développé par le Joint Video Team (JVT), groupe de travail issu de l'ISO/CEI Moving Picture Experts Group (MPEG) et de l'UIT-T Q.6/SG16 Video Coding Experts Group (VCEG). La première version de la norme a été approuvée en mai 2003 et a été régulièrement révisée avec l'ajout d'extensions jusqu'à mai 2019. Ce codec vise obtenir un bon ratio entre la qualité et des débits limités (CPO-COM), tout en conservant un niveau de complexité raisonnable (CPO-SIM). La variété de ses profils lui permet de répondre à des usages différents, avec des résolutions variables allant jusqu'à la 8K.

Bien que documenté (CPO-DOC), le codec H.264 est protégé par un ensemble de brevets déposés par différents organismes (CPO-LIB). Son usage commercial est conditionné au paiement d'une redevance auprès de la société de gestion MPEG LA. Néanmoins, la plupart des brevets portant sur H.264 doivent expirer en 2025.

À l'origine, en 1998, l'UIT-T lança ce projet dans le but de créer un codec permettant de réduire de plus de moitié le débit binaire des fichiers des standards de l'époque (MPEG-2, H.263 et MPEG-4 Part 2), de créer une interface simple afin d'adapter le codec aux différents protocoles de transport (vidéophonie, streaming, télévision, HD, mobile), mais aussi de pouvoir l'implémenter à faible coût dans les appareils. Le codec H.264/AVC est donc adapté à une très grande variété de réseaux et systèmes (diffusion télévision numérique, VOD, Blu-ray, streaming RTP/IP, et systèmes de téléphonie).

### Sociabilité

H.264 est un des codecs vidéo les plus répandus auprès du grand public et des professionnels de la vidéo (le rapport Video Developer Report de 2019 indique que 91% des développeurs utilisent ce codec). Il s'agit du format majoritaire utilisé pour la production de disques Blu-Ray ; il est également très couramment utilisé par les plates-formes de diffusion vidéo en ligne (Netflix, Amazon Prime, Youtube, etc.). C'est également dans ce standard qu'est transmise la télévision numérique terrestre (TNT) en Europe.

### Relations à d'autres formats

Schématiquement, le codec H.264 est précédé par H.262, qui avait déjà pour but la transmission de vidéo à bas débit, et est suivi par H.265 (MPEG-4 HEVC) visant l'échange de vidéos de haute qualité.

Ce codec ne doit pas être confondu avec « MPEG-4 part 2 » ou « MPEG-4 visual », qui désigne un codec vidéo fondé sur l'algorithme DCT (Discrete Cosine Transform) également employé par H.262.

### Versions

La norme H.264 se caractérise par une grande polyvalence, pour des besoins allant de la téléphonie mobile au cinéma numérique. Afin d'adapter H.264 à des usages différents, la norme définit des profils spécifiques.

Dans sa version originelle de 2003 la norme définissait trois profils, ci-dessous classés par niveau de qualité croissant :

- **Baseline Profile (BP)** : principalement pour les applications à bas coût qui utilisent peu de ressources, ce profil est très utilisé dans les applications mobiles et de visioconférence.

- **Main Profile (MP)** : à l'origine prévu pour les applications grand public de diffusion et de stockage, ce profil a perdu de l'importance quand le profil High a été ajouté avec le même objectif.

- **Extended Profile (XP)** : prévu pour la diffusion en flux (streaming) des vidéos, ce profil a des capacités de robustesse à la perte de données et de changement de flux.

En 2004, le JVT a développé de nouvelles extensions connues sous le nom Fidelity Range Extensions (FRExt). Ces extensions prennent en charge une quantification plus élevée (10-bit et 12-bit) et des structures de chrominance plus précises (YUV 4:2:2 et YUV 4:4:4). Elles visent de ce fait des applications professionnelles (post-production, tournage en haute définition). Plusieurs autres fonctionnalités ont aussi été adoptées pour améliorer la qualité subjective en haute définition ou pour des besoins spécifiques (codage sans perte, support d'autres espaces de couleurs). Ces extensions donnent lieu à la définition de quatre nouveaux profils :

- **High Profile (HiP)** : prévu pour la diffusion et le stockage sur disque, en particulier pour la télévision haute définition (HD DVD, Blu-ray, TNT), il s'agit du profil de loin le plus couramment utilisé.

- **High 10 Profile (Hi10P)** : ce profil va au-delà des applications grand public et s'appuie sur le profil High — ajoutant jusqu'à 10 bits de précision par pixel.

- **High 4:2:2 Profile (Hi422P)** : ce profil principalement fait pour les applications professionnelles s'appuie sur le profil High 10 — ajoutant le support pour la quantification 4:2:2 jusqu'à 10 bits par pixel.
<figure><img src="image_84.png" /></figure>

- **High 4:4:4 Profile (Hi444P)** : ce profil s'appuie sur le profil High 4:2:2 — ajoutant le support pour la quantification 4:4:4, jusqu'à 12 bits par pixel et en plus le support pour un mode sans perte efficace.

En outre, la norme contient quatre profils supplémentaires « AVC-I » définis comme des spécialisations de trois des sept profils précédents. Ces profils spécialisés utilisent un jeu d'outils de compression opérant uniquement en mode intra-image (chaque image est présente, entière et sans interpolation). Ce type de compression est particulièrement adapté à la post-production. Ces profils sont principalement destinés à des applications broadcast HD (actualités, publicité et cinéma) : **High 10 Intra Profile** ; **High 4:2:2 Intra Profile** ; **High 4:4:4 Intra Profile** ; **CAVLC 4:4:4 Intra Profile**.

En outre, les annexes de la norme définissent des extensions du format pour des besoins spécifiques.

L'annexe G de la norme décrit le **Codage vidéo scalable (SVC)**, extension de H.264/AVC, permettant d'offrir un contenu adaptable à différents débits et qualités. La norme contient trois profils adaptables supplémentaires :

- **Scalable Baseline Profile** : principalement destiné aux applications de vidéoconférence, de téléphonie mobile et de surveillance, ce profil s'appuie sur une version limitée du profil **baseline** H.264/AVC.

- **Scalable High Profile** : ciblant principalement les applications de diffusion et de **streaming**, ce profil s'appuie sur le profil **high** H.264/AVC.

- **Scalable Constrained High Profile** : sous-ensemble du **Scalable High Profile** destiné principalement aux applications de communication en temps réel.

- **Scalable High Intra Profile** : ciblant principalement les applications de production, il s'agit d'une spécialisation du profil **Scalable High Profile** limité au mode intra-images exclusivement.

L'annexe H de la norme décrit le codage **MVC** (Multiview Video Coding), extension permettant l'encodage de vidéo stéréoscopique et spécifiant progressivement des profils pour ces nouveaux usages.

## Conteneur

Il existe un lien structurel entre le format **conteneur MP4** et le codec H.264 : le premier est normalisé dans la partie 14 de la norme MPEG-4 (elle-même basée sur la partie 12 : « Format ISO de base pour les fichiers médias »), le second dans la partie 10.

Néanmoins, des flux vidéo H.264 peuvent se retrouver dans de multiples autres conteneurs (MKV, AVI, MPEG-PS, Quicktime, etc.).

## Organisme de maintenance et documentation de référence

Développé par le Motion Picture Experts Group (MPEG), le codec H.264 a pour organisme de maintenance l'Union internationale des télécommunications (UIT-T), qui en diffuse **une version gratuite**. Le standard a été porté à l'ISO : il s'agit de la norme ISO/IEC 14496-10 « Technologies de l'information — Codage des objets audiovisuels — Partie 10 : Codage visuel avancé ».

Un résumé **conséquent de chaque partie de la norme MPEG-4** est disponible sur l'ancien site officiel du Motion Picture Experts Group.

## Identifiants

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q212633</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000081 pour le H.264/MPEG-4 AVC<br/>fdd000082 pour le H.264/MPEG-4 AVC Baseline Profile<br/>fdd000083 pour le H.264/MPEG-4 AVC Main Profile<br/>fdd000084 pour le H.264/MPEG-4 AVC Extended Profile<br/>fdd000215 pour le H.264/MPEG-4 AVC High Profile<br/>fdd000216 pour le H.264/MPEG-4 AVC High 10 Profile<br/>fdd000217 pour le H.264/MPEG-4 AVC High 4:2:2 Profile<br/>fdd000218 pour le H.264/MPEG-4 AVC High 4:4:4 Profile<br/>fdd000162 pour le H.264/MPEG-4 AVC Non-FRExt Extensions</td></tr><tr><td>Just Solve the File Format Problem</td><td>H.264</td></tr></tbody></table>

Note : le registre de formats PRONOM ne dispose pour le moment que d'une entrée succincte sur MPEG-4.
<figure><img src="image_85.png" /></figure>

## Caractéristiques techniques

**Compacité (CPO-COM)** : le H.264/AVC cumule de nombreuses techniques d'encodage (prédiction temporelle et spatiale, adaptation des transformées discrètes, codage entropique, adaptatif ou de longueur variable, filtrage, deux modes d'entrelacement, etc.). Ces méthodes sont efficaces, et permettent, à qualité égale, de limiter le débit par rapport à MPEG-2 H.262, autorisant ainsi l'échange de vidéo haute définition. La méthode de compression très majoritairement utilisée pour encoder en H.264 est non réversible, mais il est théoriquement possible de compresser sans perte tout ou partie des zones d'image, bien que cette méthode ait pour conséquence des volumétries beaucoup plus conséquentes.

**Complexité (CPO-SIM)** : Les méthodes mentionnées précédemment confèrent à H.264 une plus grande compacité que les normes précédentes, mais également une complexité supérieure. La flexibilité introduite par ses sept profils, dix extensions, et vingt niveaux y contribue également.

**Robustesse (CPO-ROB)** : des mécanismes de résilience sont introduits dès le profil *Baseline*, et complétés dans le profil *Extended*, afin d'augmenter la tolérance aux erreurs lors de la transmission réseau. En outre, la structuration de H.264 en deux couches (*layers*) conceptuelles améliore la résilience. La couche VCL (*Video Coding Layer*) spécifie les méthodes de compression tandis que la couche NAL (*Network Abstraction Layer*) concerne l'adaptation aux protocoles de transport. Les données sont transmises en unités NAL précédées d'un marqueur spécifique, ce qui permet aux décodeurs de se resynchroniser en cas de défaillance de la transmission réseau. Pour plus de détails, on se reportera à l'article de Till Halbach et Steffen Olsen, « *Error robustness evaluation of H.264/MPEG4 AVC* », 2004, dans Proc SPIE, 5308, p. 617-627, doi:10.1117/12.522766, consultable sur https://www.researchgate.net/publication/248595612_Error_robustness_evaluaion_of_H264MPEG4_AVG.

Outre le profil, les flux H.264 sont également caractérisés par un niveau (*level*) correspondant à la définition d'un certain nombre de paramètres (taille d'image, débit, cadence) qui permettent aux constructeurs de dimensionner les ressources calculatoires et mémoire nécessaires aux appareils pour décoder une vidéo. Le tableau ci-dessous présente ces paramètres pour quelques niveaux significatifs (pour les paramètres de tous les niveaux, on se reportera à la page Wikipédia française du format H.264).

<table><thead><tr><td>N° de niveau</td><td>Taille maximale de l'image</td><td>Cadence maximale (à cette taille d'image)</td><td>Débit maximum (1) (Baseline, Extended et Main Profile)</td><td>Nb maximum d'images de référence</td></tr></thead><tbody><tr><td>3</td><td>720×576</td><td>25</td><td>10 Mbit/s</td><td>5</td></tr><tr><td>3.1</td><td>1280×720</td><td>30</td><td>14 Mbit/s</td><td>5</td></tr><tr><td>3.2</td><td>1280×1024</td><td>42,2</td><td>20 Mbit/s</td><td>4</td></tr><tr><td>4</td><td>2048×1024</td><td>30</td><td>20 Mbit/s</td><td>4</td></tr><tr><td>4.1</td><td>2048×1024</td><td>30</td><td>50 Mbit/s</td><td>4</td></tr><tr><td>4.2</td><td>2048×1080</td><td>60</td><td>50 Mbit/s</td><td>4</td></tr><tr><td>5</td><td>3672×1536</td><td>26,7</td><td>135 Mbit/s</td><td>5</td></tr><tr><td>5.1</td><td>4096×2304</td><td>26,4</td><td>240 Mbit/s</td><td>5</td></tr><tr><td>6</td><td>8192×4320</td><td>30,2</td><td>240 Mbit/s</td><td>5</td></tr></tbody></table>

## Métadonnées internes

H.264 est un flux de données vidéo et ne porte donc pas de métadonnées descriptives ; celles-ci, lorsqu'elles existent, sont codées dans le format conteneur associé.

## Outils connus par la BnF

Attention, les décodeurs ne traitent pas nécessairement tous les profils listés ci-dessus.

<footnote>(1) Pour les autres profils, le débit est à multiplier respectivement par 1,25 (High) ou 3 (High 10) ou 4 (High 4:2:2 ou 4:4:4)</footnote>
<figure><img src="image_86.png" /></figure>

Pour la manipulation et le transcodage, la BnF utilise l'outil [ffmpeg](https://www.ourcein.com/).

L'outil d'analyse et d'extraction de métadonnées techniques pour la BnF est [MediaInfo](https://www.w3.org/TR/media-info/) , qui dispose d'une sortie native dans le format de métadonnées de caractérisation préféré par la BnF, MPEG-7.

*Usage ou présence dans les collections de la BnF*

Depuis quelques années la BnF numérise certains documents avec un codec H.264 High Profile, niveau 4.1 (abrégé en HiP@4.1L) :

- Pour un signal SD (720×576), avec un sous-échantillonnage de la chrominance à 4:2:0 ou 4:2:2 et des débits de 5, 10, 20, 25 ou 50 Mb/s. Pour un signal HD (1920×1080), avec un sous-échantillonnage de la chrominance à 4:2:0 et un débit de 10 Mb/s, ou à 4:2:2 à 100 Mb/s.

Par ailleurs, le H.264 est utilisé pour la diffusion sur Gallica.

Dans les collections de la BnF sont présents, au titre du Dépôt légal ou de divers dons et dépôts, des documents
encodés avec le codec H.264.
<figure><img src="image_87.png" /></figure>

## 4.16. JPEG File Interchange Format (JPEG)

### Description

Cette fiche décrit le standard d'encodage et de compression d'images matricielles JPEG ainsi que son format conteneur le plus courant, JFIF. L'algorithme JPEG n'est applicable qu'aux images en couleur ou en niveaux de gris, non à celles binarisées. Il implique une compression forcément irréversible, appliquée à chaque enregistrement. Ce format est donc particulièrement adapté à un usage de diffusion.

### Qualité et caractéristiques du flux

Le flux image compressé selon l'algorithme JPEG ne gère qu'une profondeur d'encodage maximale de 8 bits par couche. Par conséquent, les données encodant la couleur sur 16 bits par couche seront réduites à 8 bits lors de l'encodage.

L'algorithme de compression JPEG implique l'encodage des valeurs RVB dans un modèle couleur YCbCr. La compression JPEG se fonde sur le fait que l'œil humain est moins sensible aux variations de teinte qu'aux variations de luminosité et sous-échantillonne généralement les composantes de chrominance. Les valeurs de sous-échantillonnage de la chrominance peuvent être 4:4:4 (pas de sous-échantillonnage), 4:2:2 ou 4:2:0.

### Sociabilité

Le format JFIF est très largement utilisé pour la diffusion des images en ligne. À la date de rédaction de ce document (2021), il était néanmoins légèrement moins répandu que le format PNG (voir sur le site de W3Techs, Usage of File Formats for websites).

### Versions

Il existe une méthode de compression sans perte décrite dans la norme ISO/IEC 14495, mais son usage est très limité.

### Contenu

Les fichiers JFIF contiennent plusieurs segments, introduits par des marqueurs sur deux octets (en hexadécimal, '0xFF' puis un octet spécifique au segment). Les images JFIF peuvent contenir une vignette dans un segment de marqueur APP1.

### Documents de référence

Eric Hamilton, *JPEG File Interchange Format version 1.02*, 1er septembre 1992. Disponible sur https://www.w3.org/Graphics/JPEG/jfif3.pdf (consulté le 03/12/2020). La méthode de compression JPEG est décrite par les normes ISO/IEC 10918 et ISO/IEC 14495 (compression sans perte).

### Identifiants

Extension : les extensions les plus courantes sont .jpeg et .jpg, mais on trouve également .jfif, .jpe et .jif.

Type MIME : image/jpeg.

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q26329975</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000018</td></tr><tr><td>PRONOM</td><td>fmt/42 (version 1.00), fmt/43 (version 1.01), fmt/44 (version 1.02)</td></tr></tbody></table>

### Caractéristiques techniques

Tous les visualiseurs n'étant pas à même de traiter correctement des fichiers JPEG dans un espace couleur CMYK ou CIE L*a*b*, il est recommandé d'utiliser l'espace couleur RGB.

Si la BnF est amenée à convertir en JFIF des photographies numériques livrées dans d'autres formats, elle n'appliquera pas de compression en plus de celle directement issue de l'algorithme.
<figure><img src="image_88.png" /></figure>

Le taux de compression des images JPEG est défini par plusieurs paramètres dont les plus importants sont :

* L'indice de qualité (de 0 à 100, une valeur de 80 étant souvent adoptée comme valeur par défaut des outils d'édition d'image). Il faut noter qu'en cas de ré-enregistrement, donc de ré-encodage JPEG, il est inutile d'appliquer un indice de qualité plus haut que celui choisi lors du premier enregistrement. Cela n'aurait pour effet que d'augmenter le poids de l'image sans gain de qualité.

* Le sous-échantillonnage de la chrominance. Trois modes de sous-échantillonnage sont disponibles :

* 4:4:4 (pas de sous-échantillonnage, qualité maximale donc), exprimé de la manière suivante : "1x1,1x1,1x1"

* 4:2:2, exprimé de la manière suivante "2x1,1x1,1x1 (4:2:2)"

* 4:1:1 (sous-échantillonnage maximal), exprimé de la manière suivante : "2x2,1x1,1x1".

L'algorithme de compression JPEG permet de choisir entre plusieurs modes, notamment « Baseline » et « Progressive ». Ce dernier mode optimise l'affichage pour le web en contenant un nombre paramétrable de niveaux (scans) de précision croissante, qui sont successivement chargés par le navigateur. Ce mode, quoique augmentant légèrement le poids de l'image, la rend plus résiliente car une altération sur un des scans n'affecte pas les autres (CPO-ROB). Il est donc appréciable dans une perspective de préservation à long terme.

## Métadonnées internes

Le format conteneur JFIF peut embarquer des flux complémentaires au flux image JPEG (informations sur la résolution et métadonnées aux formats EXIF, IPTC et XMP).

## Outils connus par la BnF

Les outils utilisés par la BnF sont les suivants :

- pour la caractérisation et la validation : [module JPEG de JHOVE](https://jove.cns.suisses/);

- pour la visualisation : [XnView](https://xnview.com/).

Quoique non testé par la BnF, le logiciel *Bad Peggy* est utilisé par certaines institutions de conservation pour identifier des fichiers JFIF dont le flux JPEG a été altéré (voir à ce sujet *le billet de blog d'Yvonne Tunnat*, « Error detection of JPEG files with JHOVE and Bad Peggy – so who's the real Sherlock Holmes here? » sur le blog d'Open Preservation Foundation, 29 novembre 2016).

## Usage ou présence dans les collections de la BnF

Le format JPEG a été utilisé pendant une dizaine d'années pour la numérisation de pages couleur, il a ensuite été remplacé par le TIFF non compressé, puis par le [JPEG 2000](https://www.fourrier-durand.com/).
<figure><img src="image_89.png" /></figure>

## 4.17. JPEG 2000

### Description

Cette entrée décrit le standard d'encodage et de compression d'images JPEG 2000 ainsi que son format conteneur JP2, ainsi nommé en référence à son extension (les extensions du format décrites dans la seconde partie de la norme ISO/IEC 15444 ne sont pas décrites par la fiche dans son état actuel).

L'encodage JPEG 2000 supporte une compression par ondelettes sélective (les zones identifiées comme moins riches en information seront davantage compressées).

### Sociabilité

Bien que les appareils photographiques ne puissent produire des images JPEG 2000, et que les navigateurs ne gèrent pas nativement ce format, les institutions patrimoniales sont nombreuses à l'avoir choisi (BnF, Bibliothèque du Congrès, *Wellcome Library*, *British Library*, etc.). En outre, sa variante pour l'image animée, Motion JPEG 2000, a été plus largement adoptée et est souvent proposée par les caméras numériques comme format de sortie.

### Relations à d'autres formats

Le format JPEG 2000 n'a pas de relation particulière avec le format *JFIF (JPEG)*, cependant les deux formats sont maintenus par le même groupe de travail international *Joint Photographic Experts Group*.

Le format JPX, qui utilise le même algorithme de compression, est décrit dans la seconde partie de la norme. Celle-ci définit plusieurs extensions parmi lesquelles on trouve des mécanismes de gestion de la couleur plus avancés (profils ICC complets, autres espaces de couleur que le RVB, etc.). Néanmoins, le format JPX ajoute de nombreuses autres complexités, et son support logiciel est de ce fait moins bon que celui du JP2 « simple »

### Versions

La question des versions n'est pas pertinente pour ce format.

### Contenu

Le format conteneur JPEG 2000 peut embarquer des flux complémentaires au flux image JPEG 2000 (transparence, informations sur le profil couleur et autres métadonnées).

On peut également trouver un flux JPEG 2000 dans le format conteneur JPX. Il s'agit d'une extension, définie dans la partie 2 de la norme ISO/IEC 15444, des fonctionnalités de base du conteneur défini dans la première partie. Selon les cas, les fichiers JPX peuvent être compatibles ou non avec les lecteurs de fichiers JP2.

### Organisme de maintenance et documentation de référence

Le format JPEG 2000 est maintenu par le groupe de travail international *Joint Photographic Experts Group*. Il a fait l'objet de la norme ISO/IEC 15444. Cette dernière comprend 16 parties en 2019, dont le coût total est estimé à environ 2500 €. Néanmoins, le format JP2 proprement dit est décrit par la première, qui définit notamment les caractéristiques principales de l'algorithme de compression. Cette première partie est disponible gratuitement sous sa forme approuvée en 2002 sur le site de l'ITU.

La *British Library* a réalisé une évaluation de ce format pour la préservation à long terme.

### Identifiants

Extensions: `.jp2`, `.j2k`. Les extensions `.jpx` et, plus souvent, `.jpf`, sont utilisées pour les conteneurs JPX.

Type MIME: `image/jp2`.

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q931783</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000143</td></tr><tr><td>PRONOM</td><td>x-fmt/392, fmt/463</td></tr><tr><td>Just Solve the File Format Problem</td><td>JPEG 2000</td></tr></tbody></table>
<figure><img src="image_90.png" /></figure>

## Caractéristiques techniques

Deux types de compression existent : RCT (Reversible Component Transfer), qui est sans perte (lossless), et ICT (Irreversible Component Transfer), qui implique une perte (lossy), avec chacune plusieurs niveaux de compression différents. La conversion sans perte garantit une réduction conséquente du poids des données (CPO-COM) tout en restant totalement réversible. La conversion avec perte est plus efficace que la compression JPEG ; elle permet de définir le taux de compression souhaité, ce qui devient un enjeu important et doit dépendre de la nature du document reproduit.

Les taux utilisés par la BnF sont décrits dans le référentiel BnF « Format de fichier image ». Ces taux ont été définis par une étude menée à la BnF fondée sur l'évaluation du « bruit » produit par les numériseurs. Il est fortement recommandé aux institutions patrimoniales souhaitant utiliser JPEG 2000 comme format de préservation de leurs numérisations de suivre strictement les exigences exprimées par la BnF dans ce référentiel, et notamment celles sur le taux de compression, ou à défaut de n'utiliser qu'une compression sans perte.

Il est nécessaire d'intégrer aux JPEG 2000 couleur le profil colorimétrique de l'image de la manière spécifiée dans le référentiel, section 2.3.

À condition d'utiliser les marqueurs de reprise (voir le référentiel BnF « Format de fichier image », section 2.7), le format JPEG 2000 est considéré comme particulièrement résilient en cas d'altération (CPO-ROB) (voir Buonora (Paolo), Liberati (Franco), « A Format for Digital Preservation of Images: A Study on JPEG 2000 File Robustness » dans *D_Lib*, 2008, vol. 14, numéro 7/8, consultable sur http://www.dlib.org/dlib/july08/buonora/07buonora.html).

On trouvera sur le registre des risques pesant sur les formats de fichiers, maintenu par l'Open Preservation Foundation, quelques problèmes identifiés sur le format JPEG 2000.

## Métadonnées internes

Il est recommandé d'intégrer des informations descriptives et de provenance sous la forme de métadonnées internes au format XMP. On pourra s'inspirer des pratiques BnF décrites à la section 4 du référentiel BnF « Format de fichier image ».

## Outils connus par la BnF

- Pour les images issues de la numérisation, la BnF recommande que la production soit faite avec la bibliothèque logicielle Kakadu, dans sa version 7.2.1 ou postérieure afin de convertir les fichiers bruts après qu'ils auront subi toutes les opérations de post-production. En effet, la sortie en JPEG 2000 des logiciels de numérisation est rarement assez paramétrable pour correspondre aux exigences du référentiel BnF. Un autre outil de production, non utilisé par la BnF, est la bibliothèque _open source_ [OpenJPEG] (https://www.openjpeg.org/). Sur les outils d'encodage et décodage, on se reportera aux deux ressources suivantes :

- W. Palmer, P. May, et P. Cliff, « An Analysis of Contemporary JPEG2000 Codecs for Image Format Migration », in *Proceedings of the 10th International Conference on Preservation of Digital Objects*, 2013. Disponible sur : https://purl.pt/24107. [Consulté le: 13 juin 2024]

- J. van der Knijff, « Six ways to decode a lossy JP2 », Open Preservation Foundation Blogs, 26 septembre 2014. Disponible sur : https://openpreservation.org/blogs/six-ways-decode-lossy-jp2/. [Consulté le: 13 juin 2024]

- Pour la visualisation, la bibliothèque logicielle Kakadu (notamment l'outil kdu_show) ou un visualiseur compatible IIIF (sous réserve que l'image soit diffusée par un serveur IIIF).

- Pour la caractérisation et la validation, l'outil Jpylyzer, dans sa version 2.0.0 ou postérieure. Ses rapports techniques sont convertis par la BnF vers le formalisme recommandé de métadonnées techniques pour les images : Metadata for Images in XML (MIX).

## Usage ou présence dans les collections de la BnF

Le format JPEG 2000 a été adopté par la BnF comme format préférentiel pour la numérisation de documents plans à partir de l'année 2015, en remplacement progressif du format TIFF.
<figure><img src="image_91.png" /></figure>

## 4.18. Matroska (MKV) (conteneur)

### Description

Le format Matroska, également nommé « MKV » pour Matroska Video selon une de ses extensions majoritaires, est un format conteneur audiovisuel open source et basé sur la structure EBML (Extensible Binary Meta Language). Il est issu d'un projet démarré en 2002 visant à créer un format de conteneur « streamable » pouvant embarquer dans un seul fichier un nombre illimité de flux vidéo et audio, d'images et de sous-titres, ainsi que des métadonnées et d'autres types de données tels que des menus (similaires à ceux des DVD) et des données « complexes » (logos, boutons et commandes).

Le créateur du format, Steve Lhomme, en aurait conçu le projet en 2001 afin d'enregistrer les débats de l'élection présidentielle française.

### Sociabilité

La sociabilité du format (CPO-SOC) est satisfaisante dans les différentes communautés (grand public, professionnelle et institutions de conservation).

Les fichiers Matroska sont pris en charge par plusieurs lecteurs disponibles sur les principaux systèmes d'exploitation. En particulier, Windows 10 le gère par défaut. C'est également le cas de plusieurs navigateurs (Google Chrome, Microsoft Edge, etc.).

La communauté de la préservation numérique s'oriente vers ce format conteneur (avec un flux vidéo au format FFV1 et un flux audio au format FLAC ou LPCM pour les images animées depuis plusieurs années, que ce soit pour les films ou la vidéo. Depuis 2023, la Bibliothèque du Congrès le classe parmi ses formats préférés (il était jusque-là considéré comme « acceptable »). Le British Film Institute, la New York Public Library et Meemo (l'institut flamand pour les archives) figurent parmi ses utilisateurs institutionnels.

### Relations à d'autres formats

Le format Matroska s'appuie sur le format Extensible Binary Meta Language (EBML), un dérivé d'XML sous forme binaire.

Le format vidéo WebM est basé sur un profil du format de conteneur Matroska, complété par un flux vidéo au format VP8 et un flux audio au format Vorbis.

### Versions

La version actuelle de Matroska est la version 4. Les versions 1 à 3 ne sont plus maintenues (leur documentation est toujours accessible mais aucune évolution ne sera proposée pour ces versions). Une étude de l'Université d'Indiana (Casey (Mike), Encoding and Wrapper Decisions and Implementation for Video Preservation Master Files, white paper, Indiana University, 2017, accessible sur https://mdpi.iu.edu/doc/MDPIwhitepaper.pdf) le décrit comme « mature et stable ».

### Contenu

Un fichier MKV peut contenir plusieurs « segments » (à confirmer : le site web et cette présentation se contredisent) contenant eux-mêmes des pistes. Les pistes peuvent avoir les types suivants : video, audio, complex, logo, subtitles, buttons, control, metadata.

Matroska peut embarquer des flux audio, vidéo et sous-titres dans un très grand nombre de formats. Pour plus de détails, on se reportera à la page « Codec mappings » du site de référence. Le format peut aussi théoriquement embarquer un contenu 3D, mais cette fonctionnalité est encore à ses débuts et donc très rarement utilisée.

Un conteneur MKV peut également embarquer des fichiers attachés arbitraires (notamment : illustrations, polices pour afficher les sous-titres, voire le codec audio ou vidéo afin de limiter le risque de problèmes de dépendances (CPO-AUT)).

Un des objectifs de Matroska était d'intégrer des menus similaires à ceux d'un DVD, mais la spécification reste, sur ce point et à la date de janvier 2024, à l'état de brouillon.

Ange Albertini a réalisé une description visuelle de la structure d'un fichier MKV.

### Organisme de maintenance et documentation de référence

Matroska est un projet open source réunissant de multiples contributeurs. L'organisation de maintenance, la Matroska Development Team, est une association de type loi 1901 basée en France (son créateur et développeur
<figure><img src="image_92.png" /></figure>

principal, Steve Lhomme, est français). En outre, la communauté de la préservation numérique a lancé un processus de normalisation auprès de l'IETF porté par le groupe Codec Encoding for LossLess Archiving and Realtime transmission (CELLAR), avec le soutien de la société MediaArea. Au 1er janvier 2024, la spécification est encore à l'état de brouillon (draft).

Les spécifications complètes du format sont également publiées sur le site officiel de Matroska.

Matroska étant basé sur EBML, la RFC 8794 décrivant ce dernier est applicable.

## Identifiants

Les extensions de fichiers Matroska sont .mkv pour la vidéo (peut inclure des sous-titres ou de l'audio), .mk3d pour la vidéo stéréoscopique, .mka pour les fichiers audio uniquement (peuvent inclure des sous-titres), et .mks pour les sous-titres uniquement.

Le type MIME non officiel video/x-matroska a vocation à être remplacé par video/matroska à mesure de l'évolution du processus de normalisation. Le couple audio/x-matroska / audio/matroska est également prévu lorsque seul un flux audio est présent dans le conteneur.

<table><thead><tr><th>Registre</th><th>Identifiant</th></tr></thead><tbody><tr><td>Wikidata</td><td>Q223535</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000342<br>fdd000374 MKV avec codec V210<br>fdd000343 MKV avec codec FFV1<br>fdd000344 MKV avec codec H.264<br>fdd000345 MKV avec codec MPEG-2<br>fdd000375 MKV avec codec YUY2<br>fdd000376 MKV avec codec UYVY<br>fdd000347 MKV avec codec MP3<br>fdd000346 MKV avec codec LPCM<br>fdd000542 MKV avec codec AAC</td></tr><tr><td>PRONOM</td><td>fmt/569</td></tr><tr><td>Just Solve the File Format Problem</td><td>MKV</td></tr></tbody></table>

## Caractéristiques techniques

La **résilience (CPO-ROB)** est un des atouts du format Matroska, conçu notamment pour être utilisé par streaming. En complément des empreintes numériques que les formats des flux audio ou vidéo embarqués peuvent prévoir, chaque « nœud » composant un fichier Matroska peut avoir une empreinte CRC interne, ce qui permet la détection et la localisation d'une éventuelle altération.

La structure du format Matroska, fondée sur EBML, un format arborescent sur le modèle d'XML mais sous une forme binaire, le rend relativement **transparent (CPO-TRA)**, mais aussi aisément extensible, donc flexible.

Matroska prévoit l'utilisation de **mécanismes de protection (CPO-PRO)**, en particulier le chiffrement de différentes composantes. Il est néanmoins exigé que le chiffrement ou la simple signature soit indiquée à l'aide d'un élément **ContentEncryption**.

## Métadonnées internes

Le format MKV définit une liste de tags descriptifs applicables à différents niveaux (à des niveaux supérieurs au fichier - album, collection, etc. - et à des niveaux inférieurs - piste, chapitre, etc.). On consultera également la page décrivant la structure des éléments pour les métadonnées descriptives des pistes (langue, nature et usage des pistes audio et textuelles : sous-titres malentendants, audiodescription, etc.).

Fondé sur le format EBML, MKV est donc extensible, ce qui permet aux utilisateurs d'y adjoindre des métadonnées internes arbitraires et adaptées à leurs besoins.

Le format gère notamment le chapitrage.
<figure><img src="image_93.png" /></figure>

## Outils connus par la BnF

La Matroska Development Team propose des bibliothèques logicielles open source en C/C++ pour manipuler les fichiers Matroska. L'outil ffmpeg gère également le format. Une liste d'outils tiers maintenue par les développeurs de Matroska est accessible sur leur site.

L'étude de l'Université d'Indiana citée plus haut décrit dans sa section 7, page 10, l'outil de production fondé sur ffmpeg utilisé pour produire des fichiers MKV FFV1.

L'outil mkvtoolnix permet de créer des conteneurs MKV à partir de contenus audiovisuels (mkvmerge), d'analyser un fichier MKV et ses pistes (mkvinfo), d'en extraire des flux (mkvextract) et d'en éditer les métadonnées internes (mkvpropedit).

Matroska dispose d'un outil de validation officiel : mkvalidator. L'outil mkclean permet de nettoyer et d'optimiser les fichiers Matroska.

La société MediaArea, sponsorisée par de nombreuses institutions de conservation internationales, a développé plusieurs outils prévus pour traiter des conteneurs MKV :

- **RAWcooked** qui permet de convertir un flux vidéo brut (une séquence d'images en TIFF ou DPX) vers un fichier MKV FFV1 FLAC. (Cette transformation est intégralement réversible.) ;

- **QCTools** qui permet de contrôler la qualité du signal vidéo à l'aide de mesures et de visualisations adaptées et qui gère les formats MKV et FFV1 ;

- **MediaConch** (pour Media CONformance CHecker) qui permet de valider des fichiers vidéo MKV FFV1 PCM, de définir un profil d'application, c'est-à-dire des contrôles supplémentaires contraignant la valeur de métadonnées du rapport de MediaInfo.

## Usage ou présence dans les collections de la BnF

À compter de 2024, Matroska est le format conteneur recommandé pour la numérisation vidéo de bandes masters.
<figure><img src="image_94.png" /></figure>

## 4.19. MBOX

### Description

MBOX est un ensemble de formats ouverts de stockage de dossiers de messagerie. Il est parfois nommé « Berkeley format ». Contrairement à d'autres formats de messagerie comme Microsoft PST, MBOX ne permet pas d'enregistrer des contenus complémentaires comme des contacts, des entrées d'agenda ou des tâches.

### Sociabilité

Il est largement utilisé dans des logiciels de messagerie (Eudora, Thunderbird, KMail, RoundCube, ...) mais aussi comme format de sauvegarde ou d'export (par exemple, GMail propose une fonction de récupération des mails au format mbox).

Les institutions de conservation l'ont majoritairement adopté, notamment du fait que l'outil de tri, empaquetage, recherche et accès aux messageries numériques ePADD l'a adopté comme format d'entrée et de sortie.

### Relations aux autres formats

Les formats MBOX sont une concaténation de messages Internet Message.

### Versions

Quatre variantes du format existent : mboxo, mboxrd, mboxcl et mboxcl2, qui se différencient essentiellement par la structure de la ligne initiale « From » et la manière d'échapper les éventuelles chaînes de caractères « From » dans le corps du message qui pourraient perturber la segmentation en messages individuels. Les fichiers MBOX étant des bases de données de messages, ils peuvent avoir été modifiés par différentes applications ayant chacune leurs pratiques, notamment pour le formatage des champs de la ligne « From » initiale.

Cette complexité rend les variantes potentiellement incompatibles les unes avec les autres et entraîne des difficultés d'identification du format. Pour plus de détail, on consultera cette page de Jonathan de Boyne Pollard.

### Contenu

MBOX permet d'embarquer une succession de messages individuels réunis dans un dossier (et non une messagerie complète : le format ne dispose pas de l'expressivité nécessaire à la description d'une arborescence de dossiers contenue dans une messagerie).

Le jeu de caractères utilisé par MBOX est l'ASCII sur 7 bits dans un flux 8 bits.

Le format MBOX est, schématiquement, la concaténation de messages individuels au format IMF défini par la RFC 2822 ou sa successeure, la RFC 5322. Le principal problème est d'identifier où commence chaque nouveau message. Le séparateur est une nouvelle ligne commençant par les lettres « From » suivies d'une espace. Néanmoins, cette série de caractères pouvant apparaître dans le corps des messages, les variantes du format ont défini plusieurs méthodes différentes pour marquer cette chaîne de caractères si elle se présentait dans le texte et n'était pas le marqueur d'un nouveau mail. Les comportements des différents logiciels vis-à-vis des différentes variantes de MBOX représentent le principal risque de restitution incorrecte d'un fichier MBOX.

Des pièces jointes de format arbitraire peuvent être insérées dans des messages, encodées en base64.

### Organisme de maintenance et documentation de référence

Le format est décrit par la RFC 4155, mémo de statut informational. Ce document n'est néanmoins pas une norme ; il tente de décrire les caractéristiques communes des formats MBOX et fait état des variantes introduites par les différentes implémentations. Les variantes elles-mêmes sont peu documentées. On citera tout de même les ressources suivantes : une page liée au manuel de l'outil Qmail et la page déjà citée de Jonathan de Boyne Pollard.

### Identifiants

Extension : .mbox, parfois .mbx. La RFC 4155 dit explicitement que cette extension n'est pas obligatoire, du fait notamment que les anciens systèmes Unix n'en généraient pas.

Type MIME : application/mbox. La RFC encourage l'utilisation d'un paramètre format pour préciser la variante de MBOX utilisée et indique que chaque valeur devrait faire l'objet d'une spécification distincte (ce qui n'a pas été fait à notre connaissance). L'absence de ce paramètre suggère que la variante est celle décrite dans l'appendice A de la RFC.
<figure><img src="image_95.png" /></figure>

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q285972</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000383<br/>fdd000384 (MBOXO)<br/>fdd000385 (MBOXRD)<br/>fdd000386 (MBOXCL)<br/>fdd000387 (MBOXCL2)</td></tr><tr><td>PRONOM</td><td>fmt/720</td></tr><tr><td>Just Solve the File Format Problem</td><td>Mbox</td></tr></tbody></table>

## Caractéristiques techniques

Le format MBOX étant un format textuel, constitué d'une concaténation de messages dont la structure est elle-même standardisée, il est simple (CPO-SIM) et facilement interprétable par des outils tels que de simples éditeurs de texte (CPO-TRA).

Néanmoins, les variantes, relativement peu documentées, introduisent un risque lié au découpage en messages individuels. En outre, la valeur de l'attribut `Content-Length` de l'en-tête du message est recopiée telle quelle et peut donc être fautive.

Il existe un risque avéré d'altération des fichiers MBOX si plusieurs applications tentent de le modifier simultanément (CPO-ROB). Afin de limiter ce risque, des mécanismes de verrouillage de l'édition ont été développés, mais la multiplicité de ces mécanismes produit est également source de risques. En outre, le format ne définissant pas de taille maximale, des fichiers MBOX très volumineux peuvent exister, et ces derniers sont davantage soumis au risque de corruption.

MBOX ne définit pas de mécanisme de protection (CPO-PRO) ni de méthode de caviardage. Les applications qui gèrent ces fonctionnalités ne peuvent donc pas les exprimer dans les structures officielles du format.

## Métadonnées internes

MBOX ne prévoit pas de métadonnées internes associées au dossier de messages. Néanmoins, il est possible d'ajouter des attributs personnalisés ; il est d'usage de les préfixer par X-. Par exemple, GMail ajoute l'attribut `X-Gmail-Labels` pour fournir l'ensemble des étiquettes associées au message.

La ligne "From " initiant chaque message mentionne l'expéditeur et la date à laquelle le message a été reçu par le système destinataire. Les autres métadonnées du message sont celles définies par le format Internet Message (par exemple, les attributs optionnels `Subject`, `Comments` ou `Keywords`).

## Outils connus par la BnF

MBOX étant un format textuel, il peut être manipulé par une très grande variété d'outils.

- **Identification** : du fait de l'existence de ses multiples variantes, l'identification du format n'est pas évidente. Ainsi, à la date du 26 novembre 2024, le registre PRONOM l'identifie par sa seule extension.

- **Production** : La BnF teste un outil développé par l'un de ses agents, Donatemail afin de récupérer au format MBOX un dossier de messagerie via le protocole IMAP.

- **Transformation** :

- L'outil Emailchemy, payant, permet de convertir de nombreux formats de messagerie vers MBOX. Son association en entrée de l'outil ePADD est prévue par ce dernier.

- La bibliothèque libpst permet de convertir des messageries PST vers MBOX et réciproquement.

- **Tri, recherche et accès** : l'outil EPADD utilise le format MBOX en entrée et permet, en particulier, de réaliser une sélection des messages, de les indexer avec des vocabulaires contrôlés, de les diffuser et de permettre une recherche plein texte.

## Usage ou présence dans les collections de la BnF

Il n'y a pas encore de fichiers MBOX dans les collections de la BnF, mais ce format est pressenti pour la réception et la conservation de messageries numériques obtenues par don (une expérimentation est en cours).
<figure><img src="image_96.png" /></figure>

## 4.20. Microsoft PST

### Description

Microsoft PST, ou « Personal folders file », est un format de messagerie électronique, enregistrant leur organisation en dossiers et leurs contenus associés (pièces jointes, mais aussi contacts, entrées d'agenda, tâches, etc.). Il dépend étroitement de son logiciel de création, Microsoft Office Outlook.

L'usage principal du format est de disposer d'une sauvegarde locale, éventuellement accessible hors ligne, de messageries.

Le format est documenté (CPO-DOC) mais propriétaire (CPO-LIB). Néanmoins, Microsoft le diffuse sous une licence relativement permissive : Open Specification Promise. Sa faible transparence et sa dépendance à des outils propriétaires amènent la BnF à lui préférer MBOX comme format de préservation, bien que ce dernier ait également des défauts.

### Sociabilité

Le format est très largement adopté par les particuliers et les administrations (CPO-SOC) du fait du caractère longtemps hégémonique du client de messagerie Outlook Express et du logiciel de serveur de messagerie Microsoft Exchange Server, qui restent aujourd'hui encore parmi les logiciels de leur type les plus utilisés (CPO-OUT).

### Versions

La variante du format créée par le pack Office dans sa version 1997-2002 repose sur un encodage de caractères ANSI ; depuis 2003, le format repose sur Unicode. En outre, la taille maximale des fichiers est différente entre les deux versions (2 Gio pour la version 1997-2002, 20 Go pour les versions 2003 et 2007, 50 Go à partir de la version 2010) grâce au passage d'une structure 32 bits à 64 bits.

Le format est mature mais toujours évolutif (CPO-STA) : au 1er janvier 2023, huit révisions majeures ont été réalisées depuis la version 1.0 de la spécification publiée en 2010.

### Contenu

Le texte des messages contenus dans un PST peut être encodé de trois manières différentes : en texte brut, en HTML ou en RTF. Il arrive que les outils autres que ceux de Microsoft ne les gèrent pas tous.

Le format PST peut embarquer tout type de fichier en pièce jointe. Une table des fichiers attachés permet de savoir aisément si chaque message en contient.

### Organisme de maintenance et documentation de référence

La société Microsoft reste l'organisation de maintenance du format et publie sa spécification (version actuelle, version archivée).

### Identifiants

Extension : .pst.

Type MIME non officiel : application/vnd.ms-outlook-pst.

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q29651120 (famille de formats)<br/>Q29651210 (version 1997-2002)<br/>Q29651228 (version 2003-...)</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000377 (version 1997-2002)<br/>fdd000378 (version 2003-...)</td></tr><tr><td>PRONOM</td><td>x-fmt/248 (version 1997-2002)<br/>x-fmt/249 (version 2003-...)</td></tr><tr><td>Just Solve the File Format Problem</td><td>Personal Folder File</td></tr></tbody></table>
<figure><img src="image_97.png" /></figure>

## Caractéristiques techniques

Le format étant binaire et sa structure éclatée, sa **transparence (CPO-TRA)** et sa simplicité (CPO-SIM) sont limitées ; son utilisation est soumise à la disponibilité d'un logiciel adapté à sa restitution. En outre, le texte des messages peut être chiffré et un mot de passe peut être exigé pour lire le contenu du message. Toutefois, ce mot de passe étant enregistré sous forme d'une empreinte CRC-32 dans le fichier, cette protection est jugée faible (CPO-PRO).

Le format PST est autonome : il embarque l'ensemble des contenus nécessaires pour représenter une messagerie. Néanmoins, il arrive régulièrement que les fichiers PST soient accompagnés de fichiers PAB (Personal Address Book) qui contiennent séparément les contacts (CPO-AUT).

Les fichiers PST peuvent s'altérer, en particulier s'ils sont proches de leur taille maximale (CPO-ROB). Microsoft fournit avec Outlook Express un outil de réparation appelé `scanpst.exe`. La vérification d'intégrité de ces fichiers peut également être compromise par le fait que l'ouverture de ces fichiers par leur application de lecture les modifie systématiquement.

Conçu comme un format de sauvegarde local de données personnelles, il est généralement jugé inadapté aux usages professionnels. Son accès en lecture et écriture est en outre coûteux en ressources disque.

On notera également qu'il est impossible de lancer une analyse antivirus sur les fichiers PST à moins qu'ils soient ouverts dans une application Microsoft (Outlook ou Exchange).

## Métadonnées internes

L'en-tête du fichier comprend une déclaration du format et de sa version, permettant une identification aisée par l'ensemble des outils dédiés à cette tâche.

Chaque item contenu dans un PST comprend également un en-tête comprenant de nombreuses propriétés. Concernant les messages, outre les champs habituels de description visibles dans un client de messagerie, l'en-tête en comprend de nombreux autres décrivant l'historique de gestion du message dans le logiciel.

## Outils connus par la BnF

Emaildehyde est un outil de conversion largement utilisé et reconnu par la communauté de la préservation numérique. Il convertit les fichiers PST vers des formats de messagerie ouverts. Propriétaire également, l'outil Aid4Mail présente des fonctionnalités similaires. La conversion vers MBOX est aussi assurée par la bibliothèque libpst.

Des bibliothèques logicielles ont été développées pour manipuler des fichiers PST, notamment en Java (java-libpst) et en C (libpff). En outre, Microsoft avait développé en 2010 deux outils utiles pour la visualisation (PST-View Tool) et la manipulation du format (PST File Format SDK, en C#). Leur maintenance semble être interrompue.

Des initiatives lancées par la communauté de la préservation numérique prennent en charge le traitement de ce format :

- RATOM, pour Review, Appraisal, Triage of Mails combine des outils d'évaluation et de tri de messages électroniques PST et MBOX.

- Mailbag propose un formalisme d'empaquetage standard d'une messagerie conservée sous de multiples formats (PST est l'un d'eux) - faisant ainsi état de l'absence d'un format idéal de préservation des messageries, et un outil open source pour produire des paquets conformes à la spécification. La spécification s'appuie sur le standard BagIt.

## Usage ou présence dans les collections de la BnF

La BnF ne conserve actuellement pas de messageries au format PST.
<figure><img src="image_98.png" /></figure>

## 4.21. MPEG-1/2 Audio Layer III (MP3)

### Description

MPEG-1/2 Audio Layer III, plus connu sous son abréviation « MP3 », est la spécification audio des standards MPEG-1 et MPEG-2. Il s'agit d'un format de compression audio avec perte fondé sur des recherches psycho-acoustiques menées par le *Fraunhofer Institute* à partir de la fin des années 1980. La méthode d'encodage repose sur des filtres visant à éliminer les informations sonores peu perceptibles par l'oreille humaine. Elle permet une réduction importante de la taille du flux de données audio (*CPO-COM*) tout en conservant une qualité de restitution couramment jugée acceptable, et donne le choix du débit selon le compromis taille-qualité souhaité. Depuis 2017, tous les brevets du *Fraunhofer Institute* portant sur ce format sont arrivés à échéance ; il est donc désormais totalement libre de droits (*CPO-LIB*).

Le format MP3 n'est pas recommandé comme format de données audio en vue de la préservation à long terme, car sa compression avec perte, appliquée à chaque enregistrement, est susceptible, à l'occasion de futures opérations de préservation, de dégrader un signal déjà écrêté. À défaut de disposer des données dans un format alternatif, sa robustesse (*CPO-ROB*), sa simplicité (*CPO-SIM*) et l'arrivée à échéance des brevets portant sur lui (*CPO-LIB*) en font un format facilement préservable.

### Sociabilité

Depuis la fin des années 1990, il est devenu l'un des formats de musique numérique les plus répandus, bien que des codecs plus performants (AAC, Vorbis, Opus, etc.) soient apparus depuis.

Il est de ce fait très largement géré par les logiciels de streaming audio, matériels audiovisuels et autres baladeurs, et également par tous les navigateurs. Dès le début des années 2000, des réseaux d'échange sur Internet via des logiciels de partage de fichiers tels que Napster ont beaucoup contribué à l'adoption de ce format par les consommateurs.

Il est utilisé comme format de diffusion majoritaire pour les livres audio sur support optique et téléchargement.

### Contenu

Le format MP3 est une simple concatenation de *frames* audio, éventuellement suivies (ID3v1) ou précédées (ID3v2). Une extension non officielle Xing a défini un en-tête, situé dans une *frame* initiale, destiné à porter des métadonnées techniques sur les *frames* audio (nombre, longueur, etc.).

Les données audio MP3 ont des fréquences d'échantillonnage de 32 kHz, 44,1 kHz ou 48 kHz avec un nombre de canaux audio de 1 à 6. Un fichier MP3 peut être mono, double mono, stéréo, joint stéréo ou multicanal (MP3 Surround). Les canaux peuvent être groupés (cas du joint stéréo et du multicanal 5.1 surround) pour tirer parti de la corrélation intercanal et augmenter la compression. Le débit binaire peut varier entre 8 et 320 kbit/s en fonction du taux et du mode de compression choisis.

Le taux de compression varie en fonction du débit binaire (*bitrate*) choisi : plus ce dernier est bas, plus le taux de compression est élevé et plus le signal est altéré. Ce format de compression avec perte utilise différentes méthodes : algorithmes de regroupements de données identiques, filtrage des hautes fréquences, application d'une courbe en fonction de l'audition humaine, suppression de signaux quasiment inaudibles et utilisation d'un modèle psycho-acoustique de compression (« effet de masque »).

On notera également que différents modes de compression sont utilisables : CBR (*Constant bitrate*) pour un débit fixe, VBR (*Variable bitrate*) pour un débit variable visant à maintenir une qualité d'écoute théoriquement constante, et ABR (*Average bitrate*) qui est un compromis entre les deux premiers types. Si le mode de compression VBR offre le meilleur rapport entre qualité et compacité, seul le mode CBR permet de diffuser un fichier en streaming.

Outre les données audio, et métadonnées internes au format ID3, la version 2 d'ID3 dispose d'un champ image pour intégrer un visuel (tous les formats d'image sont acceptés, mais les formats JPEG et PNG sont recommandés pour des questions d'operérabilité).

### Organisme de maintenance et documentation de référence

Le format est normalisé par le groupe *Moving Picture Experts Group* qui maintient les standards ISO/CEI 11172-1 (MPEG-1) et ISO/CEI 13818-3 (MPEG-2).

La *British Library* a réalisé une évaluation de ce format pour la préservation à long terme.
<figure><img src="image_99.png" /></figure>

## Identifiants

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q42591</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000012</td></tr><tr><td>PRONOM</td><td>fmt/134</td></tr><tr><td>Just Solve the File Format Problem</td><td>MP3</td></tr></tbody></table>

## Caractéristiques techniques

Un des avantages majeurs de MP3 est sa résilience (CPO-ROB) : les fichiers dans ce format restent presque toujours lisibles malgré des altérations (fichiers tronqués, mal formés, etc.). Les pratiques d'extraction et de conversion en vue de l'échange de musique ont conduit à la circulation de très nombreux fichiers plus ou moins invalides au regard de la norme, sans que cela ait nécessairement un effet perceptible lors de leur restitution.

Bien que cela soit une pratique rare, il est possible d'intégrer à chaque *frame* une empreinte numérique *CRC*. En cas d'altération du flux audio, on peut ainsi identifier la partie du fichier corrompue.

Les fichiers MP3 peuvent intégrer des mesures techniques de protection (DRM), notamment ceux diffusés par iTunes de 2003 à 2009.

## Outils connus par la BnF

Il n'existe pas d'outil de validation officiel ni développé par la communauté de la préservation numérique. On pourra néanmoins utiliser avec profit les utilitaires suivants.

- MP3 Validator, également appelé « MP3val », est un outil libre de vérification et de réparation de fichiers MP3 permettant de repérer certaines irrégularités (fichier incomplètement téléchargé, en-têtes mal formés notamment).

- mp3_check propose également la vérification de cohérence entre l'en-tête du fichier et les données audio.

L'outil d'analyse et d'extraction de métadonnées techniques pour la BnF est MediaInfo, qui dispose d'une sortie native dans le format de métadonnées de caractérisation préféré par la BnF, MPEG-7.

## Métadonnées internes

Le format MP3 permet d'embarquer des métadonnées internes au format ID3. Deux versions de ce format existent, qui diffèrent notamment par l'endroit du fichier où elles figurent (à la fin pour la version 1, au début pour la version 2).

Plus marginalement, on trouve également des fichiers MP3 comportant des métadonnées au format APE.

## Usage ou présence dans les collections de la BnF

La BnF diffuse sur Gallica ses données audio au format MPEG-1 Layer III à un débit constant (CBR) de 320 kbit/s, ce qui équivaut à un taux de compression de 4,8 par rapport à son équivalent au format PCM.

## Dépôt légal :

- La migration de support opérée par la BnF sur les livres audio, conférences et formations reçus par dépôt légal est à l'origine des fichiers MP3 conservés par la BnF.

- Certains flux rétrospectifs de musique dématérialisée sont attendus au format MP3, en l'absence d'une version non compressée en *FLAC* ou en *WAVE*.

**Autres missions nationales** : le format MP3 est représenté marginalement dans les fichiers adaptés collectés par la BnF au titre de l'exception handicap.

**Dons / acquisitions / production interne** : des fonds issus de collectes, conférences et entretiens sont présents au format MP3 dans les collections de la BnF.
<figure><img src="image_100.png" /></figure>

## 4.22. MPEG-PS (conteneur) H.262 (codec vidéo) MPEG-2 layer II (codec audio)

### Description

MPEG-2 est la seconde génération de la norme du *Moving Picture Experts Group*, intitulée « *Codage générique des images animées et du son associé* », qui définit les aspects de compression de l'image et du son, ainsi que le transport des données à travers des réseaux pour la télévision numérique. Cette fiche décrit à la fois les formats conteneurs MPEG-2, le format du flux vidéo H.262 (MPEG-2 part 2) et le format du flux audio MPEG-2 layer II (MPEG-2 part 3).

Le type MIME le plus couramment utilisé, et reconnu par l'IETF, est video/mpeg, mais on note l'utilisation de quatre sous-types également officiels liés à chaque format conteneur (video/mpv pour MPEG-1 or -2 Elementary Stream, video/mp2t pour MPEG-2 Transport Stream, video/mp1s pour MPEG-1 Systems Stream et video/mp2p pour MPEG-2 Program Stream), ainsi que d'autres types MIME (ceux-là officieux).

Ce format est normalisé à partir de 1994 sous l'identifiant ISO/IEC 13818 (**CPO-DOC**). Il s'inspire largement du premier standard **MPEG-1**, mais fait appel à des outils optimisés et adaptés aux besoins de production, stockage et diffusion de programmes audiovisuels de la SD (720 x 576) à la HD (1920 x 1080).

La quasi-totalité des brevets portant sur le format MPEG-2 a expiré, en 2018 pour les derniers d'entre eux en vigueur aux États-Unis (**CPO-LIB**).

Le format du flux vidéo est parfois également nommé « H.262 », identifiant de la norme strictement équivalente portée par l'UIT.

### Sociabilité

MPEG-2 a largement été utilisé comme format de signaux de télévision numérique transmis par ondes hertziennes, câble et satellite. Il spécifie également le format des films et programmes distribués sur DVD et d'autres disques optiques.

À titre d'exemple, la Bibliothèque du Congrès a utilisé ce format pour la numérisation de ses cassettes VHS.

### Relations à d'autres formats

Le codec vidéo MPEG-2/H.262 est très similaire à celui défini dans la norme MPEG-1 partie 2. Il lui ajoute néanmoins la gestion du mode entrelacé. Il est suivi par le codec H.264 qui est adapté à un plus grand nombre d'usages, dont la transmission réseau de vidéo HD. On notera que le codec H.263 ne répond pas aux mêmes besoins que les précédents car il a pour usage principal la visioconférence.

### Versions

La norme MPEG-2 définit plusieurs formats **conteneurs** selon l'usage prévu du contenu vidéo. On peut citer en particulier les conteneurs suivants.

- MPEG *Program Stream* (« MPEG-PS », « PS » ou « *Program Stream* ») pour des supports stables comme le DVD. Ce conteneur est défini par la norme MPEG-1 partie 1 et repris par la norme MPEG-2 partie 1 et son équivalent UIT H.222.0.

- MPEG *Transport Stream* (« MPEG-TS », « MTS » ou « *Transport Stream* », extensions .ts ou .m2ts) pour des usages de diffusion broadcast (télévision par câble ou satellite, notamment) où la transmission peut être instable. Ce conteneur est défini par la norme ISO/IEC 13818-1 (*Systems*) et son équivalent UIT H.222.0.

La norme MPEG-2 dans sa partie 2 décrit le **codec vidéo**, équivalent à l'UIT H.262, et définit six profils et quatre niveaux. Tous les profils ne sont pas utilisés à égalité ; les profils suivants semblent les plus répandus (classés par niveau de qualité croissant).

- *Simple Profile*, utilisé comme format de diffusion avec un sous-échantillonnage de la chrominance en 4:2:0. Il n'utilise pas d'image interpolée (B).

- *Main Profile* ou « *MP* », profil de base utilisé comme format de diffusion SD et HD ou pour la production et la transmission broadcast, avec un sous-échantillonnage de la chrominance en 4:2:0 avec la possibilité d'utiliser des images bidirectionnelles. Il est utilisé par le DVD et le Blu-ray, et les bouquets de programmes numériques.

- *4:2:2 Profile* ou « 422 », destiné à la production, la post-production et la transmission broadcast. Il permet d'encoder du 4:2:2 à haut débit et un GOP court ou un codage intra-image.

Les niveaux déterminent la définition maximale de l'image :
<figure><img src="image_101.png" /></figure>

- *Low Level* ou « LL » : n'accepte que les images à basse définition (format SIF MPEG-1) ;

- *Main Level* ou « ML » : niveau de base de la télévision standard de 720 x 576 ;

- *High 1440* ou « H14L » : niveau correspondant à une image haute définition à 1920 x 1440 points par ligne ;

- *High Level* ou « HL » : niveau correspondant à une image HD véritable, avec une pleine définition de 1920 x 1080.

Seules douze combinaisons profil/niveau sont autorisées par la norme MPEG-2

## Contenu

Cette fiche décrit les formats conteneurs MPEG-2 avec un flux vidéo au format MPEG-2 part 2 (H.262) et un flux audio au format MPEG-1/2 layer II (parfois appelé « MP2 »).

Pour mémoire, on signalera que le conteneur MPEG-PS peut également contenir :

- un flux vidéo au format MPEG-1 vidéo ou, plus rarement, au format MPEG-4 partie 2 ;

- un flux audio aux formats MPEG-1/2 layer III (MP3) ou, plus rarement, AAC. La gestion du multi-canal dépend du codec utilisé.

Les conteneurs MPEG-PS et MPEG-TS peuvent embarquer des données dans tout autre format sous la forme de private streams à condition d'enregistrer auprès de la Society of Motion Picture and Television Engineers (SMPTE) un identifiant de format (format_identifier). Cette méthode a notamment été utilisée pour intégrer dans des conteneurs MPEG des sous-titres ou du son au format AC-3 (Dolby Digital).

## Organisme de maintenance et documentation de référence

MPEG-2 est normalisé par la norme ISO/IEC 13818 : « Codage générique des images animées et du son associé », qui comporte, en avril 2021, onze parties. Celles concernées par cette fiche sont les parties 1 à 3. Les aspects Systèmes (synchronisation, transport, stockage) décrivent les formats conteneurs et sont définis dans la partie 1 : ISO/CEI 13818-1, correspondant strictement à la norme UIT H.222.0. Le format des flux audio et vidéo, en particulier la méthode de compression, est défini dans les parties 2, ISO/CEI 13818-2 (vidéo) et 3, ISO/CEI 13818-3 (son), correspondant à la norme UIT H.262.

Les parties 1 et 2 de MPEG-2 ont été développées en collaboration avec l'UIT-T, qui en diffuse une version gratuite !

- H.222.0, équivalente à MPEG-2 partie 1 ;

- H.262, équivalente à MPEG-2 partie 2.

## Identifiants

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q28018471</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000335 pour la famille de formats conteneurs<br/>fdd000028 pour le codec vidéo (H.262)<br/>fdd000033 pour le profil Simple du codec vidéo<br/>fdd000032 pour le profil Main du codec vidéo<br/>fdd000034 pour le profil 4:2:2 du codec vidéo</td></tr><tr><td>PRONOM</td><td>x-fmt/386</td></tr><tr><td>Just Solve the File Format Problem</td><td>MPEG-2</td></tr></tbody></table>

## Caractéristiques techniques

**Mesures techniques de protection (CPO-PRO)** : MPEG-2 partage avec MPEG-4 les mêmes mécanismes de protection, décrits dans le document *Intellectual Property Management and Protection in MPEG Standards*.

## Métadonnées internes

MPEG-2 spécifie des métadonnées techniques dans les en-têtes des *macroblocks*, des images, des séquences, etc. nécessaires à la lecture du flux vidéo.
<figure><img src="image_102.png" /></figure>

MPEG-2 n'a en revanche pas spécifié de formalisme pour des métadonnées descriptives, ce qui a conduit le groupe MPEG à normaliser MPEG-7 pour combler cette lacune.

## Outils connus par la BnF

Pour la manipulation et le transcodage, la BnF utilise l'outil [ffmpeg](https://址)。

L'outil d'analyse et d'extraction de métadonnées techniques pour la BnF est [MediaInfo](https://址), qui dispose d'une sortie native dans le format de métadonnées de caractérisation préféré par la BnF, MPEG-7.

## Usage ou présence dans les collections de la BnF

Avant de lui préférer le format [MP4 H.264](https://址), la BnF a utilisé depuis 1999 le format MPEG-2 H.262 selon les modalités suivantes.

Avec un codec H.262 Main Profile @ Main Level (abrégé en MP@ML)

- Pour un signal SD (720×576), avec un sous-échantillonnage de la chrominance à 4:2:0 et des débits de 6, 12, 15 Mb/s, avec un GOP de 12 et en CBR. Avec un codec H.262 Main Profile @ High Level (abrégé en MP@HL)

- Pour un signal SD (720×576), avec un sous-échantillonnage de la chrominance à 4:2:0 et des débits de 25 Mb/s, avec un GOP de 1 et en CBR.

- Pour un signal HD (1440×1080), avec un sous-échantillonnage de la chrominance à 4:2:0 et un débit de 25 Mb/s, avec un GOP de 12 et en CBR.

Avec un codec H.262 4:2:2 Profile @ Main Level (abrégé en 422P@ML)

- Pour un signal SD (720×576), avec un sous-échantillonnage de la chrominance à 4:2:2 et des débits de 25 Mb/s, avec un GOP de 1 et en CBR. Les signaux audio sont encodés en MPEG-1 Layer II en 384 kb/s pour les encodages Main Profile et en L-PCM pour le 4:2:2 Profile.

Dans les collections de la BnF sont présents, au titre du Dépôt légal ou de divers dons et dépôts, des documents dans un format conteneur MPEG-2 et encodés avec le codec H.262.
<figure><img src="image_103.png" /></figure>

## 4.23. MPEG-2/4 Audio (AAC) (codec)

### Description

L'AAC (Advanced Audio Coding) est un codec audio défini dans la norme MPEG-2 (partie 7) puis MPEG-4 (partie 3). Il s'agit d'un algorithme de compression audio avec perte offrant un meilleur rapport qualité/débit que l'ancien MPEG-1/2 Audio Layer 3 (MP3). Il a été conçu en 1997 par le Fraunhofer-Institut en collaboration avec AT&T, Sony et Dolby. Il s'agit d'un codec documenté et normalisé à l'ISO (CPO-DOC) mais son utilisation reste soumise à redevances (CPO-LIB). Il est conçu pour être transmis sur des réseaux à faible bande passante, donc universellement utilisé dans des applications de streaming, de distribution en ligne ou de télévision sur support mobile, mais il est possible de l'utiliser avec un débit et donc une qualité plus élevés.

En raison de sa compression avec pertes, le format AAC n'est pas habituellement considéré comme un format de données de préservation, mais l'efficacité de sa compression, son caractère documenté et sa large adoption en font un format généralement accepté, notamment comme flux audio synchronisé à un contenu vidéo compressé.

### Qualité et caractéristiques du flux

Les données audio AAC ont des fréquences d'échantillonnage de 8 kHz à 192 kHz avec un nombre de canaux audio pouvant aller jusqu'à 48. Un fichier AAC peut donc être mono, double mono, stéréo, joint stéréo ou multicanal. Les canaux peuvent être groupés (cas du joint stéréo et du multicanal) pour tirer parti de la corrélation intercanal et augmenter la compression. Le débit binaire peut varier entre 8 et 529 kbit/s en fonction du taux et du mode de compression choisi.

On notera également que différents modes de compression sont utilisables : CBR (*Constant bitrate*) pour un débit fixe, VBR (*Variable bitrate*) pour un débit variable.

Un flux AAC est constitué d'**objects**, qui peuvent être de **différents types** ; les profils (extensions) d'AAC définissent quels **objects** peuvent être embarqués. Ainsi, le profil AAC-LC n'autorise (dans sa version décrite par la norme MPEG-2 partie 7) que des **objects** de type "AAC Low Complexity".

### Sociabilité

Le format AAC est un standard internationalement répandu et adopté, notamment parce qu'il a été largement soutenu par Apple qui l'a choisi comme principal format de fichier pour ses baladeurs iPod, dans son logiciel iTunes ou sa plateforme de streaming. Apple est suivi par de nombreuses autres plateformes de streaming audio (Youtube Music, Spotify). En 2006 Sony adopte lui aussi ce format pour ses baladeurs. La RNT (radio numérique terrestre) dans son système de radio diffusion DAB+ (Digital Audio Broadcasting +) l'utilise également, dans sa version HE-AAC version 2. Enfin, de nombreuses consoles de jeu l'adoptent et il est supporté nativement par la très grande majorité des navigateurs web.

### Relations à d'autres formats

Le format de flux audio AAC a été conçu dans le but de remplacer le MP3.

Le format Unified Speech and Audio Coding (USAC), décrit dans les normes MPEG-D (ISO/IEC 23003-3) et MPEG-4 partie 3 (ISO/IEC 14496-3:2009/Amd 3), permet de conserver une qualité satisfaisante à des débits très réduits, notamment pour la diffusion radio et télévision et les réseaux mobiles. Bien que son nom commercial soit « xHE-AAC » (Extended High Efficiency AAC) il s'agit d'un format d'encodage différent de l'AAC.

La sous-partie 11 de la norme MPEG-4 partie 3 définit un format proche, ALS (pour *Audio Lossless Coding*, ou MPEG-4 ALS), qui permet une compression sans perte mais n'est pas largement adopté et ne dispose donc pas d'un bon support logiciel. Autre format lié, le HD-AAC, fondé sur la sous-partie 12 de la norme MPEG-4 partie 3 (*Scalable Lossless Encoding*) permet d'embarquer un flux AAC standard (compressé avec pertes) et un flux non compressé, afin d'assurer une diffusion adaptée à la bande passante.
<figure><img src="image_104.png" /></figure>

## Versions

AAC dispose de nombreux profils permettant de gérer de multiples extensions et de répondre à différents usages. Il est également caractérisé par des niveaux (*levels*) définissant la fréquence d'échantillonnage et le nombre de flux audio décodés simultanément. La partie 7 de la norme MPEG-2 définissait en 1997 trois profils : *Low Complexity (AAC-LC)*, la plus utilisée, la plus simple et la plus couramment gérée par les outils ; *Main profile et Scalable Sampling Rate profile (AAC-SSR)*. Après la publication de la norme MPEG-4 en 1999, de nombreux autres profils sont développés, extensions de la norme mais qui restent rétro-compatibles. Parmi ces derniers on peut citer :

- HE-AAC (pour *High efficiency*), aussi appelé AAC+, défini en 2003 et sa version 2, définie en 2004, permettent de conserver une qualité satisfaisante à des débits réduits, notamment pour le *streaming*;

- AAC-LD (pour *Low delay*), AAC-ELD (pour *Enhanced Low Delay*) et AAC-ELD version 2, optimisé pour les secteurs de la téléphonie et de la visioconférence.

## Conteneur

La norme MPEG-2 partie 7 spécifie deux formats conteneurs pour le flux audio AAC :

- ADIF (*Audio Data Interchange Format*), simple en-tête suivi du flux brut AAC, utilisé pour l'échange de fichiers (*extension*.aac);

- ADTS (*Audio Data Transport Stream*), très proche des conteneurs *Transport Stream* MPEG-1/2, qui définit des en-têtes pour chaque *frame* et permet ainsi la resynchronisation, donc le *streaming*.

À partir de la norme MPEG-4 partie 3, le codec AAC est plus généralement embarqué dans d'autres conteneurs multimédia : *MP4* le plus souvent, mais aussi *Quicktime File Format* (en particulier par Apple pour ses fichiers .m4p diffusés par iTunes), *MKV*, *AVI*, *3GP*, *3G2*, *FLV*, *F4V*, *M2TS*, *MXF*, etc. Pour le *streaming*, la norme MPEG-4 partie 3 définit également un format conteneur pour un flux AAC non multiplexé : *Low Overhead Audio Stream* (LOAS), et sa version multiplexée, *Low Overhead Audio Transport Multiplex* (LATM).

Il peut de même être associé à une grande variété de codecs vidéo.

## Organisme de maintenance et documentation de référence

Le format est normalisé par le groupe *Moving Picture Experts Group* qui maintient les normes ISO/CEI 13818-7 (MPEG-2 Partie 7) et ISO/CEI 14496-3 (MPEG-4 Partie 3, en particulier la sous-partie 4 qui définit l'AAC-LC).

Normes ISO :

- MPEG-2 partie 7 : ISO/IEC 13818-7:2006 « Generic coding of moving pictures and associated audio information — Part 7: Advanced Audio Coding (AAC) » ;

- MPEG-4 partie 3 : ISO/IEC 14496-3:2019 « Coding of audio-visual objects — Part 3: Audio ».

## Identifiants

Plusieurs types MIME sont associés aux flux AAC selon le conteneur qui les embarque : *audio/aac* (type MIME officiel enregistré par l'IANA), *audio/mp4* (AAC dans un conteneur MP4), *audio/x-m4a* (notamment pour les fichiers MP4 AAC LC issus d'iTunes), *audio/x-hx-aac-adif* (AAC dans un conteneur ADIF), *audio/x-hx-aac-adts* (AAC dans un conteneur ADTS), *audio/x-mp4a-latm* pour un flux AAC multiplexé en *streaming*, etc.

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q337594</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000036 AAC MP2 : Advanced Audio Coding (MPEG-2)<br/>fdd000112 AAC ADIF : Advanced Audio Coding (MPEG-2), Audio Data Interchange Format<br/>fdd000114 AAC MP4 : Advanced Audio Coding (MPEG-4)<br/>fdd000233 AAC MP4 LC : AAC (MPEG-4) Low Complexity Object<br/>fdd000234 MP4 FF 2 AAC : MPEG-4 File Format, V.2, with Advanced Audio Coding<br/>fdd000110 QTA AAC : QuickTime Audio, AAC Codec</td></tr></tbody></table>
<figure><img src="image_105.png" /></figure>

Just Solve the File Format
Problem

AAC

## Caractéristiques techniques

AAC dispose de mécanismes de correction d'erreur (CPO-ROB). En outre, un paramétrage optionnel d'AAC, AAC-ER (pour Error resilient) le rend particulièrement résilient en cas de transmission via un réseau de qualité variable.

Les flux AAC peuvent être protégés par des mécanismes de gestion des droits numériques (DRM), notamment ceux diffusés par iTunes (via le DRM propriétaire d'Apple, Fairplay) de 2003 à 2009 (CPO-PRO).

## Outils

De très nombreux outils permettent la lecture de fichiers AAC, ou du moins de leur partie AAC-LC, tous les lecteurs n'étant pas en mesure d'exploiter les extensions complémentaires.

On notera l'existence d'outils payants existent pour valider et analyser des flux audio AAC : AAC AUDIO VALIDATION et AAC Audio ES Viewer. Ils sont ici cités à titre informatif, la BnF ne les ayant pas testés.

L'outil open source ffmpeg et ses outils liés (ffplay, ffprobe) permettent de lire, encoder et analyser les flux audio AAC. Ffmpeg s'appuyant sur une bibliothèque AAC développée par le Fraunhofer Institut et soumise à des brevets logiciels aux États-Unis, il est nécessaire de s'assurer de disposer d'une version compilée avec l'option --enable-nonfree pour utiliser cette version officielle.

Le plugin File Integrity Verifier de l'outil Foobar2000, fondé sur ffmpeg, est capable d'évaluer l'intégrité de flux audio, dont ceux au format AAC, que ceux-ci disposent d'empreintes numériques CRC-32 ou MD5 embarquées ou non.

L'outil d'analyse et d'extraction de métadonnées techniques pour la BnF est MediaInfo.

## Métadonnées internes

Les en-têtes de chaque frame intègrent des métadonnées techniques. Optionnellement, l'empreinte numérique au format CRC-32 de la frame y est spécifiée.

## Usage ou présence dans les collections de la BnF

Le format AAC est prescrit comme flux audio pour le dépôt légal de la vidéo.

L'AAC est également le format du flux audio demandé à partir de 2012 par la BnF pour la numérisation des images animées. Le référentiel de numérisation sur les formats vidéo décrit les paramètres demandés dans ce cas, ainsi que les cas particuliers où le FLAC lui est préféré.
<figure><img src="image_106.png" /></figure>

## 4.24. MPEG-4 TT (Codec)

### Description

Le MPEG-4 Timed Text, appelé aussi MPEG-4 Partie 17, est un codec de sous-titres défini dans la norme MPEG-4 (partie 17). Ce codec est streamable, ce qui est le principal effet recherché. Comme pour des formats de sous-titres équivalents, il offre un large éventail de boîtes pour définir le style, le positionnement et la langue des sous-titres.

Sa standardisation et sa grande intégration au sein d'un fichier MP4 en font un bon candidat pour la préservation dans un conteneur de ce format.

### Qualité et caractéristiques du flux

Le contenu textuel du MPEG-4 TT est encodé en UTF-8 ou en UTF-16.

### Sociabilité

Le codec MPEG4-TT est couramment utilisé au sein d'un fichier vidéo MP4.

### Relations à d'autres formats

Il existe un lien structurel entre le format *conteneur MP4* et le codec MPEG-4 Timed Text : le premier est normalisé dans la partie 14 de la norme MPEG-4 (elle-même basée sur la partie 12 : « Format ISO de base pour les fichiers médias »), le second dans la partie 17.

Le projet GPAC a défini un formalisme textuel (`.ttxt`) pour permettre à son outil MP4Box de manipuler ce format.

### Versions

MPEG-4 TT ne dispose pas de version particulière.

### Conteneur

Un flux de sous-titres au format MPEG-4 TT est conçu pour être embarqué dans un conteneur soit *MP4* soit *3GP*.

### Contenu

Le contenu textuel des sous-titres est défini dans des « boîtes » typées `tx3g`. D'autres boîtes sont disponibles, notamment `styl` pour de définir des styles.

### Organisme de maintenance et documentation de référence

Le format est normalisé par le groupe *Moving Picture Experts Group* qui maintient la norme ISO/IEC 14496-17 (MPEG-4 Partie 17).

La norme ISO est la MPEG-4 partie 17 : *ISO/IEC 14496-17:2006* « Coding of audio-visual objects Part 17: Streaming text format ».

Cette description est également diffusée par l'organisme de normalisation pour la téléphonie mobile ETSI (*European Telecommunications Standards Institute*) sous le code *3GPP TS 26.245*.

### Identifiants

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q3273131</td></tr></tbody></table>

### Caractéristiques techniques

Le format est plutôt complexe (*CPO-SIM*) et peu transparent (*CPO-TRA*) puisqu'il se trouve entremêlé avec les autres flux.

Comme il s'agit d'un format binaire, il est plutôt compact (*CPO-COM*). Il est en outre robuste (*CPO-ROB*) puisqu'il est streamable, ce qui garantit que la perte de quelques blocs n'empêche pas le décodage du reste.
<figure><img src="image_107.png" /></figure>

Il n'inclut pas de mécanismes de protection (CPO-PRO).

## Métadonnées internes

Les métadonnées descriptives sont embarquées au niveau de la piste (boîte *trak*) comme les autres métadonnées descriptives des conteneurs MP4.

## Outils connus par la BnF

L'outil d'analyse et d'extraction de métadonnées techniques pour la BnF est [MediaInfo](https://MediaInfo.org).

L'outil [ffmpeg](https://www.omanetix.com/olution/olution-2000/olution-2000-2.html) peut le prendre comme flux en entrée ou en sortie.

Les outils de visualisation, tels [VLC](https://www.videolan.org/) ou [Media Player Classic (MPC)](https://www.mpc-ma.com/) , savent décoder et montrer ce type de flux.

## Usage ou présence dans les collections de la BnF

Ce codec est utilisé à la BnF comme l'un des codecs possibles de fourniture des sous-titres pour le dépôt légal de l'image animée, dans le cas où la vidéo associée est fournie en MP4.
<figure><img src="image_108.png" /></figure>

## 4.25. MP4 (conteneur)

### Description

Le format MP4, ou « MPEG-4 part 14 », est un format conteneur pour des contenus multimédia.

Le format de fichier MP4 connu sous le nom de « version 1 » a été publié en 2001 sous la référence ISO/IEC 14496-1:2001, en tant que révision du MPEG-4 Partie 1 : *Systems*. En 2003, la première version du format de fichier MP4 a été révisée et remplacée par le format de fichier MPEG-4 Partie 14 : Format de fichier MP4 (ISO/IEC 14496-14:2003), communément appelé format de fichier MPEG-4 « version 2 ». Le format de fichier MP4 a été généralisé dans le format *ISO Base Media File* (ISO/IEC 14496-12:2004 ou ISO/IEC 15444-12:2004), qui définit une structure générale pour les fichiers médias.

Le conteneur MP4 principalement spécifié par la norme de fichier média ISO/IEC 14496-12 est directement basé sur le format de *fichier MOV*. La structure de MPEG-4 Partie 14 est très proche de celle du format de fichier MOV, mais impose en outre la prise en charge des descripteurs d'objets initiaux (IOD) et d'autres caractéristiques MPEG.

Ce format permet d'embarquer plusieurs pistes (*tracks*) qui peuvent contenir des données de plusieurs types : audio, vidéo, image, texte (en particulier, pour les sous-titres). Comme la plupart des formats de conteneurs modernes, il permet le *streaming* en ligne.

### Sociabilité

Ce format est très largement utilisé pour diffuser de la vidéo sur le web. Normalisé, il concilie facilité de production, compression efficace et diffusion aisée. Il fait partie des formats *reconnus* par les navigateurs dans la balise `<video>`.

Enfin, son caractère multi-plateforme lui assure un support généralisé tant sur des ordinateurs que dans des appareils tels que les téléphones portables, les lecteurs vidéo ou les consoles de jeux.

### Relations à d'autres formats

Directement inspiré du format *MOV* d'Apple, qui a permis l'élaboration de la norme *ISO Base Media File Format* (ISO MPEG-4 Part 12), le MP4 en est une extension, normalisé sous la dénomination MPEG-4 Part 14.

En tant que format conteneur pour les contenus multimédia, il peut embarquer un grand nombre de codecs audio et vidéo mais aussi textuels (pour les sous-titres). On peut citer notamment :

- vidéo : H.265, H.264 ou MPEG-4 Part 2 ;

- son : AAC, MPEG-4 Part 3 ou MP3 ;

- sous-titres : MPEG-4 Timed Text.

### Versions

Formellement, il existe deux versions du format.

- Le format de fichier MP4 connu sous le nom de « version 1 » a été publié en 2001 sous la référence ISO/IEC 14496-1:2001, en tant que révision du MPEG-4 Partie 1 : *Systems*..

- En 2003, la première version du format de fichier MP4 a été révisée et remplacée par le format de fichier MPEG-4 Partie 14 : Format de fichier MP4 (ISO/IEC 14496-14:2003), communément appelé format de fichier MPEG-4 « version 2 ». C'est cette version qui est la plus utilisée et répandue.

### Contenu

Les données vidéo, audio, image ou texte (par exemple pour embarquer un visuel) sont embarquées dans des « boîtes » (*boxes*, analogues aux « atomes » du MOV). Chacune d'entre elles est identifiée par un type sur quatre octets (parfois désigné sous le vocable de *fourcc*) : par exemple *avc1* pour du H.264 ou *mp4a* pour la partie son avec *esds* indiquant le codec à utiliser.

Ces boîtes sont organisées sous forme d'arborescence. Le format MP4 est conçu pour séparer les métadonnées, qui sont toutes décrites dans une arborescence qui commence à la boîte racine typée *moov*, et les données qui sont incluses dans une ou des boîtes typées *mdat*, potentiellement dans des fichiers séparés.

Les différents types de boîte doivent être référencés dans le registre officiel des formats de fichier basés sur *ISO Base Media File Format*, *MP4RA*.
<figure><img src="image_109.png" /></figure>

## Organisme de maintenance et documentation de référence

Développé par le Motion Picture Experts Group (MPEG) en tant que groupe de travail ISO/IEC JTC-1 (JTC1/SC29/WG11), le standard est porté par l'ISO.

<table><thead><tr><td>1<sup>e</sup> date</td><td>Date actuelle</td><td>Version</td><td>Norme</td><td>Description</td></tr></thead><tbody><tr><td>2001</td><td>2010</td><td>MP4 file format version 1</td><td>ISO/IEC 14496-1:2010</td><td>MPEG-4 Part 1 (Systems), First edition</td></tr><tr><td>2003</td><td>2020</td><td>MP4 file format version 2</td><td>ISO/IEC 14496-14:2020</td><td>MPEG-4 Part 14 (MP4 file format), Second edition</td></tr></tbody></table>

En complément, dans la mesure où MP4 est une extension du format *ISO Base Media File Format*, la partie 12 de la norme MPEG-4 (ISO/IEC 14496-12) est également nécessaire pour disposer d'une documentation complète sur le format.

Un résumé conséquent de chaque partie de la norme MPEG-4 est disponible sur l'ancien site du *Moving Picture Experts Group*.

## Identifiants

Extension : .mp4. D'autres extensions de fichiers sont également utilisées, telles que .m4v, .m4p, .m4b, .m4e, .m4r ou .m4a, pour signifier qu'un seul type de données est embarqué. Types MIME : video/mp4 (contenu vidéo avec ou sans audio), audio/mp4 (contenu audio seul).

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q336316</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000037 pour le MPEG-4 « version 1 »<br/>fdd000155 pour le MPEG-4 « version 2 »<br/>fdd000137 pour le MPEG-4 Advanced Video Coding (Non-FRExt Extensions)<br/>Part 15<br/>fdd000156 pour le MPEG-4 « textual format » (XMT) Part 11</td></tr><tr><td>PRONOM</td><td>fmt/199</td></tr><tr><td>File Format</td><td>MP4</td></tr></tbody></table>

## Caractéristiques techniques

Le format MP4 est un format binaire, ce qui optimise sa compacité (CPO-COM).

Il est aisément extensible par l'utilisation de boîtes de type nouveau ou de type uuid réservés. Ces boîtes pourront être ignorées par les lecteurs ne les prenant pas en charge sans empêcher la lecture du fichier.

Le concept de boîte étant très générique, il est possible de gérer un très grand nombre de types de contenu et d'usage. Par exemple, l'ajout de boîtes de type hint autorise un usage en flux (*streaming*) des données.

Des mesures techniques de protection (CPO-PRO) peuvent être incluses en chiffrant les flux de données. Ce chiffrement est indiqué en utilisant des types de boîtes différents (par exemple, encv pour les données video ou enca pour l'audio) et en spécifiant les méthodes en utilisant le standard IPMP (*Intellectual Property Management and Protection*).

La tolérance à l'erreur est facilitée par la séparation entre métadonnées et données (CPO-ROB). Elle est néanmoins très dépendante du protocole de transport ainsi que des codecs sous-jacents.

Afin de faciliter l'édition, le format permet de référencer les composants média sans les embarquer dans le ficher. Les fichiers MP4 qui utilisent cette fonctionnalité ne sont donc pas auto-suffisants (CPO-AUT).

## Métadonnées internes

Le format définit des métadonnées internes, portées par des boîtes particulières : on citera notamment moov/mvhd, moov/udta/cprt, moov/trak/tkhd, moov/trak/udta/cprt.
<figure><img src="image_110.png" /></figure>

Par ailleurs, il est également possible d'ajouter des métadonnées en XMP, dans une boîte de type uuid. Dans ce cas, il est nécessaire de synchroniser ces informations, voir en particulier le Extensible Metadata Platform (XMP) Specification: Part 3, Storage in Files.

## Outils connus par la BnF

L'outil d'analyse et d'extraction de métadonnées techniques pour la BnF est MediaInfo, qui dispose d'une sortie native dans le format de métadonnées de caractérisation préféré par la BnF, MPEG-7.

L'outil ffmpeg permet le décodage et la conversion de et vers ce format.

## Usage ou présence dans les collections de la BnF

Depuis quelques années la BnF numérise certains documents avec un conteneur MP4 et un codec H.264.

Par ailleurs, le MP4 est utilisé pour la diffusion sur Gallica.

Dans les collections de la BnF sont présents, au titre du Dépôt légal ou de divers dons et dépôts, des documents au format MP4 et actuellement sauvegardées dans le Système Audiovisuel de la BnF.

Des partenaires de la BnF (Centre Pompidou Virtuel ou Centre National du Cinéma) reçoivent ou produisent ce format pour les films numériques.
<figure><img src="image_111.png" /></figure>

## 4.26. MUS / MUSX

### Description

Les formats MUS (versions de Finale antérieures à 2014, également nommé « Enigma Binary File ») et MUSX (versions postérieures à 2014) sont les formats natifs de l'application de composition musicale numérique Finale. Créé en 1987, Finale est à l'origine un logiciel développé par la société Coda Music pour Macintosh. Depuis, le logiciel a été repris par l'entreprise MakeMusic et était, jusqu'à 2024, avec son concurrent Sibelius, un des logiciels de composition et édition musicale assistées par ordinateur les plus couramment utilisés par les professionnels de la musique, compositeurs, arrangeurs et copistes. MakeMusic annonce que le support logiciel de Finale cesse à partir d'août 2024 et incite dès lors ses utilisateurs ice s à migrer vers sa solution successeure, Dorico.

Les formats MUS et MUSX sont utilisés lors de deux étapes du cycle de production des compositions musicales :

- Création et composition originales nativement numériques réalisées par le compositeur (étape de création) ;

- Mise au net et saisie d'une œuvre préexistante - que celle-ci ait été originellement composée sous une forme numérique ou sur un manuscrit papier - par le compositeur lui-même, ou par un copiste professionnel dans le cadre d'une prestation de « gravure musicale » (étape de finalisation).

Après quoi, la génération et l'export de dérivés (étape de diffusion), par exemple de parties musicales séparées à partir d'une partition rassemblant l'ensemble des voix instrumentales, et de fichiers de diffusion, est réalisée dans d'autres formats (PDF, le plus souvent).

Les formats MUS et MUSX sont des formats de composition musicale très répandus et ne peuvent donc être refusés par la BnF, au risque de perdre des documents de grande valeur artistique et historique. Néanmoins, en raison de leur nature propriétaire, de l'absence de logiciels autres que Finale pour restituer leur contenu, de la fin de la maintenance de ce dernier logiciel et de leur manque de transparence (jusqu'à 2014), la BnF recommande la migration urgente de ces fichiers vers le format MusicXML à l'aide de la dernière version du logiciel Finale en supplément des données originales au format MUS(X).

### Sociabilité

Jusqu'à l'annonce de son remplacement par Dorico en 2024, Finale était l'un des trois logiciels de composition musicale les plus couramment utilisés par les compositeurs ice s.

Aucune institution ayant répondu à l'enquête de l'Open Preservation Foundation sur les politiques de formats ne les identifie comme des formats préférés ou acceptés, mais la Bibliothèque du Congrès indique qu'elle possède plusieurs milliers de ces fichiers dans ses collections.

### Relations à d'autres formats

Les formats décrits par cette fiche ne doivent pas être confondus avec plusieurs formats portant également l'extension .mus, proches du format MIDI et utilisés dans le secteur du jeu vidéo.

Le format .musx est une spécialisation du format ZIP.

Le 25 août 2024 a été annoncée par l'éditeur MakeMusic la fin de maintenance du produit Finale : MakeMusic encourage alors les utilisateurs de Finale à migrer sur la solution concurrente Dorico dont la licence fait momentanément l'objet d'une promotion commerciale partenaire. Cette migration doit être réalisée par le biais d'exports de données au format MusicXML, lesquels sont ensuite réimportés par l'utilisateur ice dans Dorico.

Le format Enigma Transportable File est un format d'export ayant une structure textuelle permettant à l'origine l'interopérabilité entre projets produits par les versions Mac et Windows du logiciel. Le format Finale Performance Assessment (.fpa) a également été un format d'export de Finale dans une perspective de diffusion sur le web. Ces deux formats ont été dépréciés en 2007.

### Versions

Plusieurs versions successives du format MUS, liées aux versions du logiciel, existent. Le registre PRONOM distingue en effet les versions 1, 2 et 3 et suivantes. A partir de la version 3.5, le logiciel dispose d'une version pour le système d'exploitation Windows. De ce fait, les dernières versions de Finale ne peuvent convertir vers MusicXML que les fichiers MUS (à partir de la version 3.5) et non les fichiers produits par les premières versions de Finale pour Macintosh.
<figure><img src="image_112.png" /></figure>

## Organisme de maintenance et documentation de référence

Les formats MUS(X) sont propriétaires et leurs spécifications ne sont pas publiées. De ce fait, le niveau d'information disponible sur ces formats est jugé très insuffisant par la Bibliothèque du Congrès (CPO-DOC).

Le site officiel de Finale est https://www.finalemusic.com/

## Identifiants

Extension(s) : .mus et .musx, mais aussi .ftmx pour les fichiers de modèles (template). Avant la version 3.5, première version de Finale pour Windows, les fichiers produits par le logiciel sur Macintosh n'avaient pas d'extension.

Type(s) MIME : le type MIME (non officiel) est application/vnd.makemusic.notation.

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q105863379 (MUS)<br/>Q125947385 (MUSX)</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000632 (MUS)<br/>fdd000631 (MUSX)</td></tr><tr><td>PRONOM</td><td>fmt/1971 (MUS, v. 1)<br/>fmt/1972 (MUS, v. 2)<br/>fmt/397 (MUS, v. 3 et supérieures)<br/>fmt/1974 (MUSX)</td></tr><tr><td>Just Solve the File Format Problem</td><td>Finale</td></tr></tbody></table>

On notera que le registre PRONOM nomme ces fichiers « Enigma Binary File » en raison de leur signature numérique, acronyme qui signifie Environment for Notation Intuitive Graphic Music Algorithms.

## Caractéristiques techniques

Les fichiers MUS et MUSX sont généralement peu volumineux en raison de la nature de leur contenu mais également de la structure binaire des fichiers MUS et de la compression Deflate appliquée aux fichiers MUSX (CPO-COM).

La robustesse (CPO-ROB) et la transparence (CPO-TRA) du format MUSX tiennent de sa structure fondée sur ZIP et XML.

Aucun risque lié à une éventuelle dépendance n'a été identifié pour ces formats (CPO-AUT).

## Métadonnées internes

Le format MUSX dispose à sa racine d'un fichier NotationMetadata.xml qui peut embarquer de nombreuses métadonnées descriptives ( titre, compositeur ice, date et application de création et de modification, etc.).

## Outils connus par la BnF

- **Lecture et transformation** : Du fait qu'il est l'outil propriétaire de création des fichiers MUS/MUSX, Finale est le principal outil de lecture, édition et transformation des fichiers MUS(X). Les dernières versions de Finale (v.27) permettent des exports en MusicXML v.4, dernière version du format MusicXML ; il est donc préférable d'utiliser cette dernière version afin de migrer les fichiers MUS(X) vers MusicXML. Néanmoins, il existe d'autres outils qui importent ou exportent des fichiers MUS/MUSX selon cette page ; aucun n'ayant été testé par la BnF, celle-ci ne peut en mesurer le niveau réel de support des formats en question.

## Usage ou présence dans les collections de la BnF

Le département de la Musique de la BnF a reçu dans le cadre de plusieurs dons d'archives de compositeurs des fichiers MUS. Ces collections numériques sont identifiées par le département de la Musique soit comme des tapuscrits numériques originaux, soit comme des épreuves éditoriales.
<figure><img src="image_113.png" /></figure>

Comme précisé plus haut, à côté (et parfois à la place) de ces fichiers MUS peuvent être donnés par les donateurs des exports PDF de ces saisies, lesquels sont utilisés par les compositeurs en tant que versions de diffusion auprès de leurs clients et collaborateurs. Le département de la Musique a également pu encourager le versement par les donateurs de ces seuls exports PDF, en lieu et place des fichiers MUS, le format PDF étant alors, à l'inverse du format MUS, un format maitrisé de la Politique de formats de la BnF et de ce fait, considéré par le département de la Musique comme un format « préféré ». Ces exports PDF présentent l'intérêt d'être aisément exploitables en tant qu'artefacts de diffusion dans les interfaces de consultation et outils de la BnF, tout en étant issus du producteur du fonds et de ce fait considérés comme des archives authentiques de par cette provenance (Fonds Michael Galasso).

Suite à l'annonce de la fin de maintenance de Finale, le département de la Musique, confronté à des fonds numériques recelant uniquement des fichiers MUS, sans export PDF « authentique » issu du producteur du fonds, a mené un chantier d'exports afin de générer lui-même des artefacts de diffusion. Compte tenu des scories représentées dans certains exports PDF, le département de la Musique et le Groupe format de la BnF ont privilégié des exports en PNG 600 dpi (Fonds François Leclère).
<figure><img src="image_114.png" /></figure>

## 4.27. Native FLAC

### Description

Cette fiche décrit à la fois le format de fichier « Native FLAC » (Free Lossless Audio Codec) et le codec audio FLAC permettant une compression sans perte d'un flux audio PCM (pulse-code modulation). Ce format est ouvert, documenté (CPO-DOC) et libre de droits (CPO-LIB).

Il s'agit d'un format adapté à une diffusion en streaming, donc résilient aux altérations grâce à une structure en blocs et en frames (CPO-ROB).

### Qualité et caractéristiques du flux

Le format de flux audio FLAC gère une profondeur d'échantillonnage de 4 à 32 bits et un nombre de canaux audio de 1 à 8. Les canaux peuvent être groupés comme dans le cas de la stéréo et des canaux 5.1 surround pour tirer parti de la corrélation intercanal et ainsi augmenter la compression. Les profondeurs d'échantillonnage couramment utilisées sont 16 et 24 bits, à des fréquences d'échantillonnage de 44,1 kHz à 192 kHz et en stéréo.

### Sociabilité

Le format FLAC est très largement géré par les logiciels et matériels audiovisuels. Son adoption s'est développée à partir de 2017, date après laquelle les nouvelles versions de la plupart des navigateurs internet le gèrent.

En outre, de nombreuses institutions de conservation l'ont choisi comme format préféré à partir de 2016 : les archives nationales d'Australie, National Archives and Record Administration (USA), le Digital Preservation Service (Finlande), etc. (voir l'International Comparison of Recommended File Formats).

### Contenu

Le conteneur FLAC intègre le plus souvent des données audio PCM compressées selon l'algorithme FLAC mais il peut également intégrer des flux audio dans d'autres formats comme le MQA.

Le format FLAC permet d'embarquer un flux image fixe pour intégrer un visuel.

### Organisme de maintenance et documentation de référence

Le format FLAC est maintenu par la fondation à but non lucratif Xiph.org. Ses spécifications sont accessibles sur le site web officiel du format. En outre, le projet CELLAR vise à normaliser un format audiovisuel utilisant Matroska comme format conteneur, FFV1 comme codec vidéo et FLAC comme codec audio.

La British Library a réalisé une évaluation de ce format pour la préservation à long terme.

### Identifiants

Le type MIME non officiel du conteneur Native FLAC est audio/flac.

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q27881556 pour le format de fichier<br/>Q219848 pour le codec</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000198 (version 1.1.2)</td></tr><tr><td>PRONOM</td><td>fmt/279 (version 1.2.1)</td></tr></tbody></table>

### Caractéristiques techniques

La compression mise en œuvre par le codec FLAC permet de réduire de 30 à 70% la taille d'un flux LPCM. La réduction de taille est dépendante de la source : plus le signal est constitué d'ondes régulières (sons naturels), meilleure est la compression. Il s'agit d'une compression sans perte : si l'on encode un fichier WAVE en FLAC puis qu'on le décode à nouveau vers WAVE, le flux audio décodé est strictement équivalent (à la même empreinte numérique) que le fichier WAVE originel.

Chacune des frames dispose d'une empreinte numérique de type CRC. En outre, l'en-tête du fichier contient par défaut l'empreinte numérique MD5 de l'ensemble du flux audio non compressé (CPO-COM).
<figure><img src="image_115.png" /></figure>

Note : afin de conserver les métadonnées RIFF d'origine dans le fichier FLAC, on veillera à employer l'option `--keep-foreign-metadata` à l'encodage et au décodage.

## Outils connus par la BnF

La fondation Xiph.org développe également l'outil en ligne de commande `flac` qui permet d'encoder et de décoder des flux FLAC à partir de `WAVE`, `WAVE 64`, `RF64` et AIFF et de valider la structure du flux FLAC. La BnF recommande l'utilisation de cet outil pour l'encodage et le décodage de fichiers FLAC, dans sa version 1.2.1 (version à partir de laquelle l'outil gère l'option `--keep-foreign-metadata` qui permet de conserver les métadonnées du fichier d'origine) ou postérieure.

L'outil d'analyse et d'extraction de métadonnées techniques est `MediaInfo`, qui dispose d'une sortie native dans le format de métadonnées de caractérisation préféré par la BnF, MPEG-7.

## Métadonnées internes

Le format FLAC permet d'embarquer des métadonnées internes aux formats Vorbis et ID3. L'outil `metaflac` permet d'éditer ces métadonnées.

## Usage ou présence dans les collections de la BnF

Pour sa *sociabilité* (CPO-SOC), son caractère ouvert (CPO-DOC, CPO-LIB) et sa *compacité* (CPO-COM), liée à sa méthode de compression sans perte, FLAC a été adopté comme le format sonore préféré, à la fois pour la numérisation que pour le dépôt légal du son dématérialisé.
<figure><img src="image_116.png" /></figure>

## 4.28. OpenDocument Text (ODT)

### Description

OpenDocument (ODF) est un format de données pour les applications bureautiques : traitement de texte, tableur, logiciel de présentation, de diagramme, de dessin et base de données bureautique. OpenDocument Text en est la variante dédiée au texte formaté. Il s'agit d'un format ouvert (CPO-DOC, CPO-LIB) : les entreprises Sun Microsystems et IBM, qui ont contribué au format, se sont engagées à ne pas restreindre par brevet l'utilisation du format.

### Sociabilité

Ce format est reconnu par la plupart des logiciels libres d'édition bureautique (OpenOffice, LibreOffice, AbiWord, KWord, ...). Certains logiciels propriétaires assurent une compatibilité partielle (Microsoft Office 2007 et versions suivantes, Lotus Symphony, Google Docs, etc.).

En France, le format OpenDocument est le seul format recommandé comme format bureautique par le référentiel général d'interopérabilité depuis sa version 2.0 validée le 2 décembre 2015.

Un très grand nombre d'institutions de conservation (Bibliothèque et Archives Canada, National Archives and Records Administration aux États-Unis, etc.) le mentionnent comme format préféré pour le contenu textuel.

### Relations à d'autres formats

Attention de ne pas confondre les formats OpenDocument avec le format bureautique de Microsoft : Office Open XML, tous les deux étant des normes ISO.

Le format OpenDocument s'inspire largement du format créé pour le logiciel OpenOffice.org développé à l'origine par Sun. Il se base essentiellement sur XML pour le contenu, ce qui le rend relativement lisible par l'humain, et ZIP pour le conteneur. Il est possible d'embarquer des images dans le document. Dans ce cas la norme recommande (mais n'oblige pas) d'utiliser les formats PNG pour les images matricielles et SVG pour les images vectorielles.

### Organisme de maintenance, documentation de référence et versions

Il s'agit d'un format ouvert et normalisé par OASIS (Organization for the Advancement of Structured Information Standards) depuis mai 2005 et par l'ISO depuis 2006 sous l'identifiant ISO/IEC 26300.

<table><thead><tr><td>Version</td><td>Date OASIS</td><td>Date ISO</td></tr></thead><tbody><tr><td>1.0</td><td>01/05/2005</td><td>19/07/2006</td></tr><tr><td>1.1</td><td>02/02/2007</td><td>11/07/2013</td></tr><tr><td>1.2</td><td>29/09/2011</td><td>19/06/2015</td></tr><tr><td>1.3</td><td>en cours</td><td>N/A</td></tr></tbody></table>

La British Library a réalisé une évaluation de ce format pour la préservation à long terme.

### Contenu

Un document au format OpenDocument peut exister sous deux formes :

- généralement, un conteneur au format ZIP embarquant plusieurs fichiers XML et éventuellement du contenu binaire tel que des images ;

- plus rarement, un simple fichier XML dit « à plat », signalé par l'extension .fodt. Cette forme n'est pas toujours reconnue par les logiciels d'édition (tels que Microsoft Office 2007 à 2013).

Un fichier ODT présente obligatoirement un fichier XML : META-INF/manifest.xml qui contient la liste de fichiers contenus dans le conteneur, avec leur type MIME et éventuellement l'information nécessaire à leur décompression ou leur déchiffrement.

Un fichier ODT comporte optionnellement (mais sa présence est fortement conseillée) un fichier mimetype qui contient le type MIME du document (pour ODT : application/vnd.oasis.opendocument.text).
<figure><img src="image_117.png" /></figure>

Le contenu est réparti dans les fichiers :

- content.xml : le contenu à proprement parler du document ;

- meta.xml : les métadonnées associées au document ;

- settings.xml : des paramètres destinés à l'application pour éditer le document ;

- style.xml : la partie « présentation » du document.

On peut trouver également :

- Thumbnails/thumbail.png : une imagette enregistrée en PNG ;

- éventuellement des images dans Pictures/ : ce répertoire ne fait pas partie de la norme mais relève d'une pratique généralisée ; les images contenues dans ce répertoire devraient être au format PNG ou SVG bien qu'il soit possible d'utiliser tout autre format.

## Identifiants

Extensions : .odt, .fodt (version sous forme d'XML seul), .ott (modèle de document).

Types MIME : application/vnd.oasis.opendocument.text, application/vnd.oasis.opendocument.text-template (modèle de document).

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q27203100 (v. 1.0) Q27203404 (v. 1.1) Q27203601 (v. 1.2)</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000427 (v. 1.1) fdd000428 (v. 1.2)</td></tr><tr><td>PRONOM</td><td>fmt/136 (v. 1.0) fmt/290 (v. 1.1) fmt/291 (v. 1.2)</td></tr><tr><td>Just Solve the File Format Problem</td><td>OpenDocument Text</td></tr></tbody></table>

## Caractéristiques techniques

Le format ODF gère les marques de révision et la signature numérique à partir de sa version ODF 1.2.

Basé sur le conteneur ZIP dans sa version normalisée à l'ISO, le format ODT bénéficie des mécanismes de gestion d'intégrité de ZIP. Sa robustesse (CPO-ROB) est donc considérée comme satisfaisante. Conformément à la norme ISO ZIP (ISO/IEC 21320-1), seule la méthode de compression sans perte Deflate est autorisée.

## Dépendances (CPO-AUT) :

- Un document ODT peut inclure les polices utilisées dans le texte afin de le rendre autonome, mais tous les outils, par exemple Apache OpenOffice, n'autorisent pas cette opération.

- Les fichiers complémentaires (de type images ou autres) peuvent être inclus dans le conteneur ZIP ou simplement référencés. Selon la version de l'outil utilisée, un copier-coller d'une image dans un document ODT peut ne résulter qu'en une référence à l'URI de l'image, et non à l'inclusion de l'image elle-même.

Mécanismes de protection (CPO-PRO) : les fichiers ODF peuvent être aisément chiffrés en sélectionnant une option d'enregistrement dans OpenOffice.org et LibreOffice. Les fichiers ainsi chiffrés ne sont plus lisibles par les outils d'analyse cités plus bas qui renverront donc une erreur plus ou moins explicite. À partir de la version 1.2 d'ODF, plusieurs méthodes de chiffrement sont autorisées ; le fichier META-INF/manifest.xml doit indiquer laquelle a été utilisée.

## Métadonnées internes

Le format ODF permet d'embarquer des métadonnées internes dans le fichier meta.xml. Le formalisme adopte Dublin Core (préfixe « dc: ») et l'étend avec un jeu de métadonnées spécifique (préfixe « meta: »). Le format accepte également des métadonnées définies par l'utilisateur, qui suivent le formalisme RDF à partir de la version 1.2 d'ODF.

## Outils connus par la BnF

- De multiples outils d'édition existent, mais le formatage peut différer de l'un à l'autre (ainsi, Microsoft signale que « Le formatage peut être perdu lorsque les utilisateurs enregistrent et ouvrent des fichiers .odt »).

- La conversion de ou vers ODT est une opération délicate ; il arrive que certaines fonctionnalités soient perdues ou mal rendues (les marques de révision notamment sont souvent mal traitées).
<figure><img src="image_118.png" /></figure>

- L'outil **ODF Validator**, développé par The Document Foundation, valide les fichiers ODF et dispose d'une version en ligne. Il en existe d'autres, mais aucun ne propose une couverture complète du format.

- Tika permet une extraction des métadonnées internes au format XMP et du contenu textuel.

## Usage ou présence dans les collections de la BnF

À la date du 16 mars 2021, le format ODT est peu représenté dans les collections de la BnF. Il est néanmoins susceptible de les intégrer par le biais de dons numériques natifs.
<figure><img src="image_119.png" /></figure>

## 4.29. PDF

### Description

Le format PDF a été intialement développé par la société Adobe pour présenter une combinaison d'éléments graphiques, textuels et interactifs dans une mise en page constante quel que soit l'environnement de consultation et l'équipement d'impression. Le format est présenté à la conférence dédiée aux systèmes d'exploitation Windows et OS/2 en janvier 1993 et le premier logiciel produisant ce format est commercialisé par Adobe en juin 1993.

Au fil du temps, le format a connu de multiples versions qui ont étendu ses fonctionnalités. En outre, des variantes spécifiques à certains secteurs d'activité l'ont spécialisé pour embarquer des contenus de nature très diverse (cartographie, création graphique, correspondance, modèles 3D, etc.). Il s'agit donc plutôt d'une famille de formats, mais nous utiliserons par commodité le singulier dans la suite de cette fiche.

Il s'agit d'un format propriétaire mais Adobe a publié ses spécifications sous forme de plusieurs normes ISO à partir de 2008 (CPO-DOC). Bien qu'Adobe ait déposé des brevets logiciels sur le format (CPO-LIB), il promeut son utilisation en ne demandant pas de redevance aux applications qui lisent et produisent des fichiers PDF.

Du fait de son adoption généralisée, le format PDF est un format incontournable dont il est nécessaire de connaître les multiples usages et complexités, ainsi que la multiplicité des outils logiciels qui le prennent en charge.

### Sociabilité

Le format est omniprésent dans tous les secteurs d'activité. Néanmoins, la couverture réelle des outils est généralement beaucoup plus réduite au regard des fonctionnalités proposées par les spécifications.

Selon un comptage réalisé en 2021 sur un échantillon, PDF est le troisième format le plus présent en ligne, devant tous les formats d'image (Johnson (Duff), « PDF's popularity online », PDF Association, 10 septembre 2021. Accessible sur https://pdfa.org/pdfs-popul.arity-online/ (consulté le 3 mars 2025)).

### Relations à d'autres formats

Le format PDF dérive du langage Postscript dont la vocation est de construire une page comprenant des éléments textuels et vectoriels afin de pouvoir les imprimer avec une mise en page constante. Adobe a stoppé les développements de ce langage en 2007, PDF en étant un des successeurs.

### Versions

Les versions successives de PDF ont ajouté de nouvelles fonctionnalités et ont enrichi et complexifié la structure du format (CPO-STA). On notera notamment les versions suivantes, associées à certaines évolutions majeures :

- 1.0 (1993) ;

- 1.1 (1996) : autres espaces couleur que RGB, protection par mot de passe, contenus multimédia et hyperliens ;

- 1.2 (1996) : modèle couleur CMJN, compression Deflate (ZIP), caractères Unicode, formulaires ;

- 1.3 (2000) : profils ICC, signatures numériques, contenus interactifs Javascript, chiffrement par l'algorithme RC-4 ;

- 1.4 (2001) : transparence, balisage de la structure du texte ;

- 1.5 (2003) : calques (layers), compression JPEG 2000 ;

- 1.6 (2004) : chiffrement AES, encapsulation de fichiers, contenus 3D au format U3D, filigrane ;

- 1.7 (2006) : paramétrage par défaut de l'impression, fonctionnalité de caviardage (redaction) ;

- 2.0 (2017/2020) : chiffrement AES-256, données de géoréférencement, améliorations diverses.

On trouve un résumé des principaux points saillants de chaque nouvelle version dans la [cheatsheet sur les bases du PDF](https://github.com/mblanc/cheatsheet/blob/master/PDF.md).

En outre, plusieurs variantes du format ont été développées pour des usages spécifiques ; il s'agit toujours de spécialisations intégrant des contraintes supplémentaires adaptées aux besoins de chaque secteur d'activité. On citera notamment :

- PDF/A pour l'archivage, spécialisation très restreinte aux fonctionnalités ne risquant pas de poser de problème de préservation à long terme ;

- PDF/E pour l'ingénierie, spécialisation permettant d'embarquer des modèles 3D (la PDF Association recommande désormais d'utiliser de préférence la norme PDF/A-4e pour ce cas d'usage) ;

- PDF/X pour l'impression (« X » pour « exchange ») ;

- PDF/UA pour l'accessibilité (« UA » pour « universal accessibility ») ;
<figure><img src="image_120.png" /></figure>

- PDF/R pour le transport et la conservation d'images fixes issues de la numérisation (« R » pour « raster »).

On se reportera à cette page pour une description de ces variantes par la PDF Association.

## Contenu

PDF est un format textuel comprenant des parties binaires embarquées dans des *object streams* dont l'encodage est spécifié dans leur attribut \Filter. Pour en savoir plus, voir *la présentation d'Ange Albertini sur l'anatomie d'un PDF*.

Les PDF issus d'une numérisation peuvent être constitués d'une simple série d'images, une par page, mais les PDF nativement numériques sont le plus souvent beaucoup plus complexes et composés d'une combinaison d'éléments textuels, vectoriels ou matriciels, voire interactifs, superposés.

## Texte

Le format PDF peut embarquer du texte, mais il est présent sous forme de glyphs (forme typographique d'un caractère dans une police donnée) localisés sur la page par des coordonnées. Cette caractéristique rend souvent problématique l'extraction de texte depuis un PDF. Pour plus de détails, voir le billet de blog « What's so hard about PDF text extraction? », accessible sur https://web.archive.org/web/20230107081641/https://filingdb.com/b/pdf-text-extraction.

Le PDF peut contenir une description arborescente de la structure logique du document, à partir d'un *object* nommé *Structure Tree Root* (*StructTreeRoot*). Des pointeurs situés dans cette arborescence font le lien avec les objets décrivant des contenus textuels ou images. La présence de cette description logique est conditionnée à l'intégration de tels éléments à l'étape de création du fichier.

## Polices

Le PDF peut embarquer en totalité ou partiellement les polices de caractères utilisées dans les éléments textuels, ce qui est recommandé afin de garantir une restitution fidèle : si la police choisie n'est pas embarquée et n'est pas disponible sur la machine du lecteur, elle sera remplacée par une police de substitution, ce qui pourra affecter sensiblement la mise en page.

Dans le cas où la présence des polices dans le fichier fait craindre leur récupération, il est possible d'embarquer uniquement le sous-ensemble des caractères effectivement utilisés dans les éléments textuels, ou bien même de vectoriser le texte.

## Images

Les images embarquées dans un PDF peuvent être encodées selon différents algorithmes de compression :

- Réversibles, adaptés aux images binarisées : CCITT Groupe 4, JBIG2 ;

- Réversibles, adaptés à tout type de données : Deflate (ZIP), LZW, RLE ;

- Avec pertes : JPEG ;

- Avec ou sans pertes : JPEG 2000.

Chaque image, décrite comme un *object* dans le PDF, dispose d'un attribut *Filter* qui indique le type de compression ; sa valeur est respectivement : « CCITTFaxDecode », « JBIG2Decode », « FlateDecode », « LZWDecode », « RunLengthDecode », « DCTDecode », « JPXDecode ».

## Signature numérique

Le format PDF gère des mécanismes de **signature numérique (CPO-PRO)**.

## Autres contenus

Le PDF peut contenir un très grand nombre de contenus :

- Zones de formulaire ;

- Hyperliens ;

- Contenus audio et vidéo ;

- Contenus 3D ;

- Commentaires ;

- Boutons et éléments interactifs en Javascript.

Certaines de ces fonctionnalités (les formulaires, par exemple) ne sont gérées correctement que par Adobe Reader.
<figure><img src="image_121.png" /></figure>

Les PDF de type « portfolio » sont des conteneurs arbitraires embarquant toutes sortes de fichiers, mais même dans le cas d'un PDF « standard », il est possible d'embarquer des flux de toute nature dans des objects contenant des flux (streams).

Parmi les usages envisagés du PDF, on peut citer l'archivage des courriers électroniques. La PDF Association, en collaboration avec des institutions de conservation, a décrit une spécialisation du PDF répondant à cet usage (voir l'annonce de cette publication).

## Organisme de maintenance et documentation de référence

Initialement développé par Adobe, le format PDF est dpuis 2008 normalisé à l'ISO sous l'identifiant ISO 32000. Du fait que l'évolution du format est désormais soumise à la révision de la norme ISO, Adobe a depuis cette date proposé des extensions pour ses besoins propres. On mentionnera les suppléments « extension level 3 » qui ajoute notamment l'incorporation de données géoréférencées et la gestion du chiffrement AES-256 et « extension level 5 ». Ces extensions ont été intégrées dans la norme PDF v. 2.0.

La PDF Association met gratuitement à disposition la norme ISO 32000-2:2020, correspondant à la version 2.0 de PDF, à cette adresse. Elle propose également de très utiles cheatsheets, mémentos rappelant de manière concise et rapide les principes de PDF.

Johann van der Knijff (Bibliothèque royale des Pays-Bas) réunit sur son blog Bitsgalore une documentation conséquente sur les risques de préservation posés par le format PDF. On se référera utilement à son billet sur l'identification de risques à l'aide des outils JHOVE et veraPDF.

## Identifiants

Extension(s) : .pdf.

Type(s) MIME : application/pdf.

<table><thead><tr><td>Registre</td><td>Identifiant</td></tr></thead><tbody><tr><td>Wikidata</td><td>Q42332 et un item par version du format</td></tr><tr><td>Bibliothèque du Congrès</td><td>fdd000030 et de nombreux autres pour les versions et variantes du format</td></tr><tr><td>PRONOM</td><td>Un identifiant par variante et version du format, voir ce tableau</td></tr><tr><td>Just Solve the File Format Problem</td><td>PDF</td></tr></tbody></table>

## Caractéristiques techniques

Le format PDF est notoirement un format complexe du fait de sa structure, de la diversité des contenus et de la multiplicité des encodages que ces contenus peuvent adopter (CPO-SIM). Il s'agit d'un format textuel intégrant des parties binaires sous forme de flux (streams). Sa transparence est limitée par un éventuel chiffrement et les couches d'encodage divers des chaînes de caractère et des flux (CPO-TRA). Les opérations suivantes peuvent être envisagées dans le but de comprendre la structure et diagnostiquer des problèmes de restitution :

- Déchiffrement du PDF (par exemple avec la ligne `qpdf --decrypt`);

- Décodage des flux et encodage des flux binaires en hexadécimal avec la ligne de commande `mutool clean -da`;

- Production d'une version inspectable et éditable par un éditeur de texte à l'aide de la ligne de commande `qpdf --qdf`.

Les PDF sont souvent relativement compacts car les images embarquées peuvent être compressées à l'aide de divers algorithmes.

## Taille de la page

La taille d'une page d'un PDF se trouve dans un object de type `MediaBox`, en nombre de points (le point étant par défaut 1/72e de pouce ; ainsi, une page A4 dans une résolution de 72 ppp aura souvent pour valeurs 0 0 595 842). Il est possible de spécifier en supplément une taille plus réduite dans un object de type `CropBox`. C'est cette portion, plus réduite, qui sera affichée par un lecteur, les parties marginales restant invisibles. (Cette fonctionnalité permet
<figure><img src="image_122.png" /></figure>

notamment, pour les PDF à imprimer, de placer des chartes couleur CMJN qui ne seront donc pas visibles dans le
produit final.)

Modifications incrémentales

Lorsqu'un PDF a été édité, il est parfois possible de revenir à son état précédent à condition que la modification ait été enregistrée sous forme de modification incrémentale (incremental update). Dans ce cas, l'outil enregistre les nouveaux objects ou redéfinit des objects existants à la suite du marqueur de fin de fichier %EOF. De ce fait, supprimer ce qui suit le(s) marqueur(s) %EOF dans un éditeur hexadécimal permet de restaurer la (les) précédente(s) version(s) du PDF. Il est cependant recommandé de le faire avec un outil spécialisé. On peut notamment citer l'outil Apache Tika qui, utilisé avec l'option -z peut extraire du PDF la version antérieure, tout comme l'outil PDFResurrect.

Sécurité et chiffrement

L'ouverture d'un PDF peut être protégée par la définition d'un mot de passe de type user. Cette protection
restreint l'ouverture et la consultation du contenu du fichier ; la protection est variable, de très faible (RC4 40 bits)
à très solide (AES-256). Dans ce cas, les outils d'analyse (Apache Tika, JHOVE, veraPDF, etc.) échouent
également à analyser le contenu du PDF et renvoient une erreur plus ou moins explicite.

En complément, le format PDF définit un certain nombre d'autorisations protégeant l'impression à basse ou haute
définition, l'extraction de contenu pour des besoins d'accessibilité ou non, l'assemblage, le commentaire, le
remplissage de formulaire et toute autre modification. La protection des PDF passe par un chiffrement du texte et
des flux (stream objects) du PDF et la définition d'un mot de passe de type owner/creator. Il est possible de connaître
les actions interdites sur le fichier grâce à la commande **qpdf --show-encryption**. Un tel chiffrement,
contrairement à celui qui conditionne l'ouverture du PDF à l'entrée d'un mot de passe, est souvent aisé à
supprimer grâce à la commande **qpdf --decrypt**. Par ailleurs, ces autorisations ne sont qu'indicatives et le
choix de les respecter ou non repose sur les logiciels de lecture et édition de PDF.

Linéarisation

Les PDF peuvent être « linéarisés » (linearized) afin d'optimiser leur transfert par réseau et donc leur visualisation en ligne. Un PDF linéarisé peut ainsi être affiché progressivement à l'utilisateur ice sans attendre son téléchargement complet.

Métadonnées internes

Le format PDF peut embarquer des métadonnées internes au format XMP.

Une [liste de propriétés signifiantes des fichiers PDF](https://www.adobe.com/editions/ephenry/k10000000000000000000000000000000.html) a été proposée par Tyler Thorsted.

Outils connus par la BnF

Un billet du blog Bitsgalore précédemment cité réunit une liste très complète d'outils pour travailler avec le format PDF.

- Lecture : il existe de nombreux logiciels, mais, bien que tous tentent de restituer des documents mal formés, leur tolérance à l'erreur est variable. Un PDF peut donc être illisible avec un lecteur et s'afficher avec un autre. Adobe Reader est le plus complet ; bien qu'il soit distribué gratuitement, il n'est pas libre. L'outil de lecture Sumatra, disponible exclusivement sur Windows, a l'avantage d'actualiser le PDF en temps réel lorsque le fichier est modifié dans un éditeur en parallèle.

- Inspection et débogage : Apache PDFBox dispose d'une commande debug qui permet d'inspecter la structure du PDF et ses objets en en donnant une représentation visuelle parallèle. L'outil MuPDF dispose d'utilitaires utiles pour obtenir des informations sur le PDF, y compris sur ses problèmes de structure (mutool info <nom_de_fichier>), recalculer les offsets des objets composant le PDF et leur longueur (mutool clean <nom_de_fichier>) et décompresser les flux binaires si l'on souhaite explorer le PDF (mutool clean -d <nom_de_fichier>).

- Validation : outre le module PDF de JHOVE, de nombreuses bibliothèques et outils en ligne de commande renvoient des erreurs et avertissements utiles à la compréhension d'éventuels problèmes de structure. On en trouvera une liste dans la section « Validation and integrity testing » du billet de blog de Johan van der Knijff déjà cité. La validation du PDF est une opération complexe et il est de ce fait recommandé de comparer les résultats de plusieurs outils afin d'évaluer la validité des PDF. Une solution simple et apparemment efficace avec ExifTool est proposée dans ce billet de blog : Tunnat (Yvonne), « PDF Validation with ExifTool - quick and not so dirty », Open Preservation Foundation, 4 février 2022. Accessible sur https://openpreservation.org/blogs/pdf-validation-with-exiftool-quick-and-not-so-dirty/ (consulté le 4 novembre 2024).
<figure><img src="image_123.png" /></figure>

- **Caractérisation et extraction de métadonnées** : on se reportera de même au [billet de blog de Johan van der Knijff déjà cité](https://johandknijf.com/), section « Document information and metadata extraction ».

Attention à ne pas enregistrer un PDF ouvert dans un éditeur de texte : cela modifie généralement les espaces et corrompt la table des offset de chaque object.

## Usage ou présence dans les collections de la BnF

De très nombreux PDF ont été collectés dans le cadre de l'archivage du web. En outre, le format ou l'une de ses variantes est un format privilégié par la BnF pour l'obtention des versions finalisées des contenus de notation musicale, d'édition numérique, de cartographie avec ou sans géoréférencement et de création graphique.
<figure><img src="image_124.png" /></figure>

## 4.30. PDF/A

### Description

PDF/A est une série de déclinaisons standardisées du format de publication PDF destiné à préserver la mise en page du document. Cette série de formats est utilisée pour conserver et échanger des documents numériques car les restrictions qu'elle impose au format PDF visent à le rendre autonome (CPO-AUT). Son développeur, l'entreprise Adobe, bien que disposant de brevets portant sur le format, accorde une licence gratuite pour la visualisation et l'édition de ces fichiers par des logiciels tiers (CPO-LIB).

PDF/A, dans ses versions 1 et 2 (la version 3, en incluant la possibilité d'embarquer n'importe quel type de contenu, comporte des risques supplémentaires), réduit sensiblement les risques portant sur le contenu des fichiers qui s'y conforment. Néanmoins, dans la mesure où il restreint fortement les contenus et les fonctionnalités des documents bureautiques, une conversion vers ce format présente des risques de perte d'information qui ne peuvent être limités que par une maîtrise des formats source et cible, et un contrôle rigoureux des propriétés signifiantes des données résultant de l'opération.

Pour une vue d'ensemble du format et de ses usages, on pourra consulter le document : PDF/A l'essentiel 2.0 : PDF pour l'archivage à long terme. Une introduction technique en anglais est également disponible : A Technical Introduction to PDF/A, PDFlib, 2017.

### Sociabilité

La série de formats PDF/A est très largement utilisée et recommandée par de nombreuses organisations officielles et institutions de conservation aux États-Unis et en Europe. Les implémentations par des outils très largement répandus tels Microsoft Office, LibreOffice ou InDesign contribuent à la diffusion du format auprès du grand public.

### Relations à d'autres formats

PDF/A est une stricte restriction du format PDF. Il hérite de ce fait des complexités et ambiguïtés du format PDF, bien que celles-ci aient été limitées dans la version 2.0 de PDF, dont dérive PDF/A-4.

Bien que non directement lié, le format PDF/UA-1 (pour Universal Accessibility), normalisé comme ISO 14289-1:2014, impose et précise l'usage des balises PDF (tags) qui encodent la structure sémantique du PDF. De ce fait, la conformité à ce standard est recommandée par Adobe aux créateurs de PDF/A de variante « a ».

### Versions

<table><thead><tr><td>Date</td><td>Version PDF/A</td><td>Version PDF de base</td><td>Norme ISO</td></tr></thead><tbody><tr><td>2005</td><td>PDF/A-1</td><td>PDF 1.4</td><td>ISO 19005-1</td></tr><tr><td>2011</td><td>PDF/A-2</td><td>PDF 1.7 (ISO 32000-1)</td><td>ISO 19005-2</td></tr><tr><td>2012</td><td>PDF/A-3</td><td>PDF 1.7 (ISO 32000-1)</td><td>ISO 19005-3</td></tr><tr><td>À venir</td><td>PDF/A-4</td><td>PDF 2.0 (ISO 32000-2)</td><td>ISO 19005-4 en cours</td></tr></tbody></table>

### Contenu

Les principales restrictions introduites par PDF/A sont les suivantes.

- Il ne peut contenir que du texte ou des images à condition qu'elles ne soient pas compressées avec l'algorithme LZW.

- Les formats audiovisuels ainsi que les interactions (Javascript, etc.) sont par conséquent interdits.

- Les polices doivent être incluses dans le fichier (on relève de ce fait des risques potentiels si les polices en question sont protégées par le droit d'auteur).

- L'inclusion des profils colorimétriques des images (généralement sous forme de profil ICC ou de spécification CIE Lab) et la présence de métadonnées au format XMP sont obligatoires.

- Le chiffrement est interdit (CPO-PRO).

Les contenus et fonctionnalités suivants sont introduits dans la version PDF/A-2 (ils étaient interdits dans la version PDF/A-1) :

- format d'image JPEG 2000 (introduit en PDF 1.5) ;
<figure><img src="image_125.png" /></figure>

- gestion de la transparence ;

- introduction de spécifications sur la signature électronique (déjà possible pour PDF 1.4 et donc PDF/A-1, mais sans précision sur sa forme) selon le format PAdES ;

- possibilité d'inclure des fichiers PDF/A-1 ou PDF/A-2, pour permettre la création d'un unique fichier PDF/A-2 issu de plusieurs d'entre eux.

### Apport de la version PDF/A-3 :

- possibilité d'inclure n'importe quel fichier associé au document ou à une de ses pages, à condition de fournir un type MIME et la relation entre le contenu associé et le contenu principal selon une liste fermée (source, data, alternative, supplement, unspecified). Les logiciels de lecture de PDF/A ne sont tenus que de permettre l'extraction du contenu attaché. L'objectif initial était de pouvoir ajouter le fichier d'origine, avant conversion vers PDF/A, mais, cette liberté ayant été employée à des usages divers, elle est aujourd'hui considérée comme faisant porter un risque de préservation supplémentaire. Elle est donc généralement déconseillée par les spécialistes de la préservation numérique.

Du fait du caractère restrictif du PDF/A, le choix de la version à utiliser est directement lié au contenu que l'on cherche à porter ; les versions successives de PDF/A ne remplacent en aucune façon leur prédécesseur.

## Organisme de maintenance et documents de référence

Les formats PDF/A sont maintenus par Adobe et normalisés par l'ISO, voir le paragraphe *Versions*.

Requête sur les variantes du format et leur norme ISO associée sur Wikidata.

La British Library a réalisé *une évaluation de ce format* pour la préservation à long terme.

### Identifiants

<table><thead><tr><th>Registre</th><th>PDF/A</th><th>PDF/A-1</th><th>PDF/A-2</th><th>PDF/A-3</th></tr></thead><tbody><tr><td>Bibliothèque du Congrès</td><td>fdd000318</td><td>fdd000125</td><td>fdd000319</td><td>fdd000360</td></tr><tr><td>Wikidata</td><td>Q1547957</td><td>Q26543628 (b)<br>Q26541013 (a)</td><td>Q26546575 (b)<br>Q26547266 (u)<br>Q26545877 (a)</td><td>Q26548590 (b)<br>Q26549229 (u)<br>Q26547917 (a)</td></tr><tr><td>PRONOM</td><td></td><td>fmt/354 (b)<br>fmt/95 (a)</td><td>fmt/477 (b)<br>fmt/478 (u)<br>fmt/476 (a)</td><td>fmt/480 (b)<br>fmt/481 (u)<br>fmt/479 (a)</td></tr></tbody></table>

Les variantes sont les suivantes :

- « b », pour « basic », correspond aux exigences minimales pour la restitution à long terme de l'apparence visuelle de la mise en page.

- « u », pour « unicode », ajoute à la variante « b » l'exigence de disposer pour tout le texte d'un équivalent en Unicode pour permettre la recherche et l'extraction du texte.

- « a », pour « accessible », ajoute des exigences sémantiques (tags) pour documenter, comme dans un format de balisage, la nature des contenus (titres, tableaux, listes, etc.), leur organisation logique au sein du document, décrit comme une structure arborescente, et son ordre de lecture, notamment en vue de favoriser l'accessibilité.

### Caractéristiques techniques

Le poids (CPO-COM) d'un fichier PDF/A peut être sensiblement plus important que celui d'un PDF en raison des contenus obligatoires (polices, profils colorimétriques) ou des fichiers embarqués.

Certaines dépendances externes (CPO-AUT) peuvent malgré tout exister dans un fichier PDF/A : liens hypertextes vers une ressource web, ou encore action GotoR (lien vers un emplacement dans un autre fichier PDF).

### Métadonnées internes

La présence de métadonnées internes au format XMP, reposant sur le formalisme RDF, est obligatoire.
<figure><img src="image_126.png" /></figure>

Outre les centaines de propriétés définies par XMP, ce format est extensible à des métadonnées déterminées par l'utilisateur, mais PDF/A impose, dans ce cas, que ces propriétés soient documentées par l'inclusion d'un schéma d'extension (XMP Extension Schema Description).

## Outils connus par la BnF

Pour la production, les outils bureautiques (en particulier, Microsoft Word à partir de 2012, et LibreOffice Writer à partir de la version 6) sont en mesure de générer un PDF/A, moyennant une configuration lors de l'enregistrement.

L'outil de lecture Adobe Acrobat Reader sait détecter la présence de la déclaration du caractère 'A' du PDF (dans les métadonnées XMP), et le notifie par la présence d'une bannière. Tous les lecteurs de PDF sont en mesure de lire des fichiers PDF/A, mais certains ne traitent pas correctement ses particularités (non exploitation des profils colorimétriques, des polices embarquées ou des fichiers attachés, notamment). Il en est de même pour les outils de conversion de ou vers PDF/A qui ne gèrent pas tous correctement les fonctionnalités et contenus du PDF/A (transparence, signature électronique, etc.). Une conversion de masse PDF vers PDF/A est donc une opération périlleuse et requiert la plus grande prudence : une vérification après génération est fortement conseillée pour s'assurer qu'aucun élément n'a été supprimé ou mal représenté.

- veraPDF est un outil spécialement conçu pour valider le PDF/A.

- Le module PDF de JHOVE permet une caractérisation du format PDF et une détection du profil PDF/A.

- Tika permet une extraction des métadonnées internes au format XMP et du contenu textuel.