Les nouveaux containers multimédias commencent peu à peu à sortir de l'ombre. D'abord avec l'ogg (pas le format audio), ou plutôt l'ogm, puis matroska, mais également le standard MP4, on a vu se populariser des solutions jugées plus intéressantes que le vieillissant .AVI. Ces containers permettent en effet de muxer une piste ogg vorbis ou aac dans un film, pour y associer plusieurs pistes sons ou des sous-titres, voire de grapiller quelques précieux mégas-octets dans le simple travail de mux. La réalité des atouts de ces containers me parait trop évidente pour qu'on la discute.
 
Depuis quelques temps, on voit également apparaître de nouveaux usages pour ces containers, en les réservant à l'audio (CD-RIP) seul. L'intérêt serait de n'avoir qu'un fichier par album, contenant les tags individualisés, divers documents (fichiers logs, paroles, voire même pochettes scannées). L'avantage tiré de n'avoir qu'un fichier monolithique, qui par simple ajout dans la playlist ferait éclore les pistes originales comme par enchantements est compréhensible : on limite les dossiers et facilite l'organisation. Ceci dit, nul besoin de passer par un container pour celà : un fichier .cue et un lecteur supportant cela suffisent (Winamp, foobar2000). Ce mode a aussi ses inconvéniants : impossible par exemple de graver une piste ou de l'ouvrir dans un éditeur sans passer par des manoeuvres pour l'isoler du gros fichier mère. La compatibilité n'est pas totale non plus, et un certain nombre de formats audio ne sont pas supportés (mpc, monkey's audio...). Quant à l'intérêt d'associer des scanns de jaquettes dans un même fichier, les plus sceptiques diront qu'ils n'en verront pas l'utilité, et les plus sarcastiques ajouteront que cela servira essentiellement aux intérêts du P2P.
 
Alors, que pensez-vous de ces containers et de cet usage particulier ? Est-ce pour vous un truc de pirate, un trip pour accros de l'informatique éloigné des intérêts de la masse et donc de l'industrie ? Ou au contraire est-ce une innovation essentielle apportant son lot de solutions à des problèmes divers ?
 
 
Personnellement, d'abord intéressé par la chose, elle m'apparait finalement comme particulièrement lourde, peu flexible, voire finalement bien peu utile, du moins en l'état actuel des choses.

Pas trop l'intérêt en l'état actuel :
- l'essentiel de ma collection est au format Musepack
- j'ai passé mes anciens mp3 dans un container mp4 pour les tagger proprement
- quelques sauvegardes (images) au format ape + cue + pdf (pour les jaquettes) : 3 fichiers et basta!

Les containers me paraissent une solution élégante à certaines problématiques:
 
*Permettent d'ajouter les informations gapless sans avoir à les incruster dans les données passées au décodeur (à la façon Lame). En effet, ces infos interessent le player, pas la couche de décodage pur.
 
*Idem pour les informations de seek
 
*Idem pour les méta-données interessantes: niveau sonore, langue,...
 
*Permettent d'associer au fichier des informations complémentaires: image, paroles, lien web. Si vous ne possedez pas de support physique, ces infos sont très interessantes. C'est par exemple le cas avec les music stores.
 
*Permettent d'avoir dans un meme fichier plusieurs versions de la piste: par example une présentation en plusieurs langues
 
*Permettent d'associer d'autres pistes complémentaires, par exemple des sous titres. Avec les solutions de type Lyric3, ces infos sont regroupées en un gros block monolythique. Comment alors les streamer par la suite?
 
Ce qui manque actuellement, c'est à mon sens des softs simples pour manipuler ces containers.
En tant qu'utilisateur, je trouverais beaucoup plus simple d'avoir un gros fichier par album, qui contienne les pistes, leur ordre et d'autres infos comme le livret, plutot que d'avoir plusieurs fichiers.
Si je veux ensuite extraire l'un des pistes pour la mettre sur mon balladeur, il est beaucoup plus simple de le faire depuis un containeur que depuis une fichier son unique et un .cue.

Toutes les ogccasions detournées sont bonnes pour faire un sujet sur le P2P  a ce que je vois
 
Sinon les containers oué pourquoi pas, ca peut servir dans le milieu professionnel aussi , pour faire une video avec plusieurs bandes son

Merci pour avoir pris le temps de lister ces atouts, effectivement intéressants  

A l'heure actuelle, cela me semble encore assez laborieux, dans les deux cas. On verra par la suite ce qu'il advient des outils de création/extraction.

As-tu pris le temps de simplement lire le titre du topic ? Je parle de l'intérêt de ces outils appliqué à l'audio uniquement, et tu réponds vidéo  

 
Les bandes son c est de l audio

Le mot "uniquement" t'est-il étranger, ou faut-il que quelqu'un se charge de te l'expliquer ?

 
C est toi meme qui parle de film en ligne 5  

Visiblement, c'est la notion même de pensée qui t'es étrangère. Une introduction, non, ça ne te dit rien... Allez, va polluer ailleurs.

La premiere phrase que j ai ecrit ne t a pas plu ?

Question d'outils.
 
Le problème avec un unique fichier audio et un .cue, c'est que séparer les pistes n'est pas possible de manière propre avec les codecs qui utilisent des trames (ie MPC, Vorbis, MP2, MP3, AAC).
Le .cue c'est bon pour la lecture, c'est tout.

Je suis entièrement d'accord : les possibilités sont à l'heure actuelle bridées par la complexité des outils nécessaires à leur exploitation.  
Par ailleurs, il semble qu'aujourd'hui ces containers soient réservés aux rips mono-fichiers : on extrait le CD en un bloc, puis on utilise le .cue pour créer des plages virtuelles. De fait, tu ne peux extraire des plages individuelles, du moins pas avec des fichiers lossy. Dès lors, les containers m'apparaissent à l'heure actuelle (je précise) comme une solution très proche de celle qui consiste à utiliser un fichier .cue avec un fichier audio traditionnel. Normallement, l'utilisateur devrait pouvoir rassembler un ensemble de fichiers au sein d'un même container, mais je n'ai pas encore vu un utilisateur mentionner cet usage, et j'ignore si les outils actuels permettent de réaliser cela.

 
Je dis peut-être n'importe quoi, je ne m'y suis pas suffisamment intéressé, mais j'ai utilisé OggPreview avec fb2k et il me semble qu'il fait ça. D'ailleurs, je ne vois trop l'intérêt d'un container qui ne ferait que remplacer le fichier .cue.
 
Plus généralement, je pense que Gabriel a bien résumé les principales applications des containers dans le domaine de l'audio, et que les outils permettant de les exploiter au mieux manquent encore à l'appel.

Je ne sais pas. J'ai le sentiment qu'il encode les pistes de manière fusionelles et qu'il créé un index après coup. Je fais peut-être erreur. En tout cas, oggpreview ne permet pas d'assembler plusieurs fichiers choisis par l'utilisateur en un seul fichier.
A l'heure actuelle, l'engouement (relatif) pour les containers audio prend pour point de départ le rip du CD lui-même : il faut que le fichier soit mono-bloc, et il faut le .cue associé pour que le container joue son rôle. C'est très restrictif comme usage (impossible par exemple de réaliser simplement deux fichiers matroska si le CD est composé de deux parties distinctes ; impossible également de créer simplement un fichier matroska ou mp4 unique pour un album tenant sur plusieurs CD).
D'où mon sentiment, que l'intérêt actuel porté aux containers ne concerne que les accros de la question, ne touchant qu'un nombre restreint d'utilisateurs.

J'ai toujours eu du mal à en comprendre l'intérêt, de même que pour les fichiers cue (surtout quand le format d'encodage est déjà gapless).

Actuellement, je suis d'accord.
Mais mon opinion est que serait fort avantageux de les utiliser.
 
Quand tu achètes un cd audio, tu as une boite en plastique qui contient un livret, une jaquette arrière, un cd. Sur ce cd il y a plusieurs pistes (on a pas 10cd d'une piste dans la boite).
 
Personnellement, je trouve que c'est fort pratique que les 10 pistes soient sur une seul cd (et pas 10), que le cd et le livret puissent tenir dans la boite.
Pour les containeurs, c'est pareil. Je trouve plus simple et plus élégant d'avoir un containeur avec tout dedans plutôt que 12 fichiers (10 pistes audio, une playlist et un pdf)
 
Si ton album est sur plusieurs cd, ou que tu as un "coffret", et bien alors 2 choix: un unique containeur ou des containeurs multiples.
Un containeur par cd (tes boitiers cd et ce qu'il y a dedans), en un containeur global référençant les pistes situées dans les autres containeurs (l'équivalent du coffret dans lequel il y a les boites de cd)

+1 que nyarla, en plus je fais parti des sarcastiques

Quand je vois la peine qu'ont beaucoup d'utilisateurs pour des opérations aussi simples et effectuées avec des outils aussi efficaces que sont le dé-/multiplexage ou le taggage, je me dis que des containers emboités en poupées russes avec 36 formats et 50 types d'infos différentes à stocker dedans, ça va être la zizanie...

Pourtant il ne viendrait à l'idée d'aucun utilisateur de word de faire un fichier par paragraphe et de stocker ses styles à l'extérieur du document...

 
J'y vois quelques inconvéniants. Par exemple, je souhaite lire le texte scanné du livret. Avec des fichiers images séparés, un double click me permet de les ouvrir dans un visualiseur (et tous les avantages que cela implique : grossissement, recompression, navigation, cataloguage...). C'est enfantin. Je peux même les zipper si je souhaite ne pas voir une myriade de scanns représentés par autant de fichiers : Windows gère les zip, ACDSee aussi...
Idem pour les informations figurant en fichier texte. Elles sont facilement visualisables, éditables, réenregistrables. Je me vois mal corriger une faute dans un .rft en devant préalablement extraire le fichier du container, puis le réinsérer avec un outil spécifique : les manipulations suplémentaires deviennent rapidement fastidieuses, et pour quel gain ? Si je souhaite trouver une information dans les .rtf (un mot précis, une référence à un lieu, à un compositeur), je peux utiliser la fonction recherche de Windows (search for "Leporello" in *.rtf in D:\MUSIC) : en quelques secondes, les fichiers seront scannés, et les occurences trouvées. Cette fonction est inutilisable avec un container (search for "Leporello" in *.mka : il y en aurait pour des heures entières).
Bref, l'intégration de documents dans un même fichier conduit à un ensemble de manipulation superflue dès lors qu'il s'agit de visualiser, d'éditer, cataloguer, réencoder... Sincèrement, l'intérêt, séduisant sur le plan théorique, me semble du coup absolument nul d'un point de vue pratique. D'où ma supposition : que ce système soit surtout intéressant pour le P2P, dont le succès repose sur la multiplication des sources, ce qui implique que l'utilisateur n'aie pas à modifier ses fichiers originaux. Les archives téléchargées en .zip sont souvent décompressées puis rapidement effacées, ce qui conduit à la disparition des sources alors que paradoxalement les fichiers se répendent graduellement... Le container permettrait d'offrir un fichier unique, exploitable sans trop de contraintes, et donc laissé comme tel (sources accrues).
Quant à l'utilisateur qui décide d'utiliser régulièrement les fichiers embarqués, lui risque d'être enquiquiné.
 

Mais là on sort brise la logique du fichier par album. Pourquoi avoir quatre fichiers pour un seul et même opéra ? Pourquoi quatre et pas 40, comme c'est le cas avec le fichier/piste ? En procédant ainsi, on réduit le nombre de fichier, mais l'on reproduit la logique que l'on voulait initialement abandonner.
 

Tu veux dire un fichier qui rassemblerait plusieurs containers qui eux même rassemblent différents fichiers ? Ma foi, je n'y avais pas pensé. Mais est-ce seulement autorisé par les standards ? Est-ce gérable par les lecteurs ?

C'est pour les mêmes raisons que le avi est en perte de vitesse.
C'est un format µ$oft. Suffit de voir la taille d'un .doc avec 3 mots dedans.

 
Pas plus qu'il ne viendrait à l'idée d'un concepteur web d'utiliser des includes de fichiers et une feuille de style externe.
Hop, une petite comparaison bienvenue.

Les containers permettent d'associer des éléments hétérogènes (texte, image, vidéo...) ; dans ton exemple, les éléments que tu cites sont homogènes.
Le problème ne réside peut-être pas tant dans la possibilité de stocker plusieurs pistes en un fichier, que dans celles de l'assemblage d'éléments hétérogènes (hétéroclites ?). Pourquoi vouloir tout réunir en un truc, sachant que les logiciels ne sont pas programmés pour lire les éléments contenus dans ces fichiers (foobar2000, winamp, wmp... ne pourront que difficilement lire les .rtf, les .png contenus dans un .mka, et encore moins les exploiter autrement qu'en simple lecture). Et si la solution multilogicielle est préférable pour gérer de multiples médias, la solution multifichier n'en est-elle pas le pendant logique ?

 
Si si ma soeur a fait ça une fois, 1 fichier par chapitre    
 
Mais on en revient au même point. sous Word, c'est fait de façon transparente, alors que pour Mastroska et les autres, aucun outil ne le permet. La remarque de Guru sur la recherche est intéressante, mais la fonction rechercher de Windows ne serait peut-être pas la plus appropriée pour trouver un texte dans un livret. Ce serait plutôt une idée à implémenter dans un lecteur multimédia spécialisé dans ce type de fichier.

Ca sent les bons vieux topic à Ciler du vendredi

foobar2000 (je sais, y en a que pour lui   ) dispose d'un outil de scann approfondie des tags, qui permet de faire cela. C'est très efficace (comprendre : rapide) car les informations sont contenues dans la base de donnée, mise en mémoire : en une minute, tu peux réaliser plusieurs dizaines de recherches C'est sans doute plus efficace qu'un outil de recherche qui devrait préalablement accéder à l'ensemble des fichiers textes nichés quelque part dans un container.

gURuBoOleZZ, je pense que tu parles des containeurs MAINTENANT.
Moi, je parle des containeurs THEORIQUEMENT.
Dans ce que j'indique, je fais abstraction de la non disponibilité actuelle des logiciels de manipulation et de la non prise en charge actuelle des containeurs par les lecteurs multimédia.
 
Si l'on regarde la situation actuelle, alors non il n'y a pas beaucoup d'avantages à utiliser à outrance des containeurs pour l'audio. La seule utilisation actuelle est en gros ITunes music store qui inclus une image dans les mp4 vendus, image affichée par le player ITunes.
 
Mais si l'on ne regarde que les possibilités réellement pratiquables aujourd'hui, alors forcément on ne verra jamais d'évolutions ni de changements apparaitre.
 
Le concept de containeur existe. Les containeurs peuvent-ils apporter quelque chose à l'utilisateur? C'est ce dont nous sommes en train de discuter.
Le fait qu'ils n'apportent aujourd'hui pas grand chose doit-il avoir pour conséquence que l'on ne réfléchisse pas à ce qu'ils pourraient apporter ou non? Je dis non.
 
Je pense que bon nombre de personnes ici sont capables de faire la part des choses entre l'état actuel d'une technique ou d'outils, et les capacités potentielles. C'est de l'informatique, quelque chose que nous pouvons construire.
 
Il faut juste, lorsque l'on discute, préciser si l'on constate on si l'on envisage.

Ou alors, envisager une gestion du container au niveau de l'OS, de façon que cela soit fait de façon transparente (autrement dit, pas besoin d'un logiciel ad hoc et spécifique pour accéder au contenu du contenant... heu...).
 
Un peu à la façon de l'accès 'transparent' au contenu des archives Zip dans certains OS : j'accède sans même le savoir aux divers fichiers compressés, tout en pouvant tout déplacer/supprimer d'un bloc, tout échanger d'un bloc avec mes collègues...

ok, donc pour résumer, les containers, ce sera bien.

 
Je comprends très bien. Bien que cela semble prétentieux et grossièrement nietzschéen, j'essaie de me situer par delà la théorie et l'actualité. Certes, les containers permettent de faire pas mal de choses en théorie. Certes, des solutions logicielles permettraient de les exploiter pleinement. Mais il demeure un obstacle : pourquoi tous les logiciels devraient-ils s'adapter pour offrir des possibilités :  
-1. que seule une partie des utilisateurs réclame.
-2. d'ores et déjà exploitables sans passer par un container.
 
Tu cites l'exemple des images embarquées dans le container MP4 proposé par iTunes : on peut faire de même avec l'ID3v2 (un des anciens Archos proposait même de les afficher sur son écran couleur "timbre-poste" ). Tu cites la possibilité d'ajouter des informations techniques, permettant entre autre le gapless : c'est possible avec les tags, c'est possible avec l'en-tête (cas du mpc il me semble).
 
Bien entendu, le container reprend ses possibilités tout en en ajoutant d'autres : c'est là son intérêt. Reste à en connaître le prix. Car combien de temps faudra-t-il pour que les logiciels populaires intègrent ces techniques, complexes (rien qu'à voir la quantité de problèmes répertoriés avec foo_mka, on comprend que la gestion d'un container n'est pas une mince affaire) ? Combien de temps faudra-t-il pour que l'industrie décide à son tour d'en supporter toutes les applications ? Car c'est une chose de dire que les containers permettent EN THEORIE plein de bonnes choses, c'en est une autre que de créer les outils qui permettront de les utiliser toutes. Toi qui travaille sur du MP3, pourtant infiniment plus simple qu'un container avancé, tu as pu constater combien l'industrie et l'édition peinait à supporter l'intégralité du freeformat : le VBR supporté partiellement, le freeformat ignoré, les frames de grandes tailles oubliées... Autre exemple : l'ID3v2. Ce format controversé pour des raisons de compatibilités entre versions offre un grand nombre de champ : mais trouve un logiciel qui les exploite tous (fb2k excepté) ? Trouve un lecteur qui en supporte ne serait-ce que 10% ?
 
Bref, l'édition et l'industrie ont montré qu'ils rejettaient les solutions complexes, ou que si elles étaient acceptées, c'est de façon extrêmement limitative et délibéremment lacunaire (sans doute pour des raisons économico-techniques). A moins que la mentalité ne change (ce qui me semble hautement improbable), parler des atouts THEORIQUES des containers me parait ressembler à ces projets politiques utopiques du XIXème siècle, dont leurs auteurs disaient : "mais oui ils sont possibles" en dépit des critiques adressée au sujet de leur possibilité de réalisation :
 

Ce ton me rapelle étrangement celui des encouragements adressé par les harangueurs à la foule, qui essaie d'y croire. Mais pour parvenir à la réalisation des beaux projets, il faut passer des obstacles - et comme autrefois, le principal réside dans les considérations économiques, dominantes et déterminantes jusqu'à l'heure actuelle.

Tout à fait. Ce sont les considérations économiques qui dictent la marche à suivre.
 
Ce sont des considérations économiques qui font que Lame est intégré dans des logiciels commerciaux.
Ce sont des considérations économiques qui font qu l'on trouve des lecteurs "divx" (en fait mp3+ mpeg4 ASP dans de l'avi) à la pelle.
Il est même possible que ce soit des considérations économiques qui fassent que FhG laisse les développeurs de Lame tranquilles.
Ce sont des considérations économiques qui font que Apple place des images dans ses fichiers MP4.
 
Si un outil apporte globalement quelque chose à l'utilisateur, alors le bon sens économique fait que l'industrie supportera cet outil.

C'est une vision très optimiste. Beaucoup de technologies innovantes ne sont pas supportées massivement par l'industrie, pour des raisons économiques : formats Real, MP3pro, Dataplay... l'histoire des techniques est une cimetière d'outils qui n'ont pas perçé. Soit pour des raisons de brevets (donc économiques), soit pour des raisons d'impopularité (donc économique). Lorsque les industriels suivent en masse des technologies brevetées (tel le MPEG-4, ou LAME) c'est très généralement de manière minimale : on offre la simplicité, et l'on dissimule beaucoup des points intéressants qui constituent pourtant l'outil dans son ensemble, et qui le rendait intéressant

je sens déjà que la partie orienté objet de la norme MPEG4 va passer à la trappe, vous ne voulez quand même pas que la partie container disparaisse également ?
je vote pour le container offre des posibilités élargies et je vais de ce pas déposer un cierge pour que la norme MPEG-4 soit rapidement utilisée dans son intégralité (bref que les outils sortent !)

Pareil je suis un optimiste aussi.. Vivement les containers audio supportés partout...

hum, c'est dommage, a un jour près, sa aurait fait 1 mois

En 1 mois ils ne sont tjrs pas supportés partout??? Quelle honte!!

obiwan number one dans le sondage

est-ce qu'ils existent une platine divx qui sait lire les matroska ?
Est-ce que c'est prévu ? Une simple mise à jour du firmware suffirait ?