FR 2768843 A1 19990326 FR 9811919 A 19980924 DOMAINE DE L'INVENTION La présente invention concerne le domaine de l'édition audio/vidéo. Plus spécifiquement, la présente invention concerne un procédé et un appareil pour éditer des données audio/vidéo numérisées sur un réseau. DESCRIPITION DE L'ART ANTÉRIEUR Présentement, I'édition audio/vidéo est le plus fréquemment utilisée conformément au système représenté sur la figure 1. Une station de travail d'édition inclut de nos jours des disques locaux sur lesquels une information audio/vidéo est stockée. L'édition peut être réalisée via un écran d'affichage mais elle est limitée aux données audio/vidéo stockées localement. Ce type de système assure une fonctionnalité insuffisante pour éditer une quantité importante de données audio/vidéo stockées sur de multiples stations de travail. Plus spécifiquement, ce système est insuffisant du fait que les stations de travail d'édition courantes ne réalisent pas une édition sur les frontières de stations de travail sur des réseaux. Des données audio/vidéo sur chaque station de travail doivent être éditées séparément et la sortie de l'édition peut alors être entrée dans une console de mixage ou mélange afin de créer une sortie audio/vidéo finale. S'il y a un quelconque problème en relation avec la sortie audio/vidéo finale, alors le processus d'édition fastidieux des diverses pistes de données audio/vidéo qui résident sur chaque station de travail séparée doit être répété. Ce processus se poursuit jusqu'à ce que la sortie finale soit satisfaisante. RÉSUME DE L'INVENTION La présente invention décrit un système et un procédé permettant de constituer une interface utilisateur configurable en relation avec des données audio/vidéo (AN). Selon un mode de réalisation, un moteur de descripteur de données est couplé au système de fichiers AN qui contient les données AN/V. Un type d'interfaçage utilisateur sur l'interface utilisateur graphique (GUI) est identifié. Un générateur d'affichage accède au système de fichiers AN et génère un affichage des données AN en fonction du type d'utilisateur. Un constructeur de menu génère des options/caractéristiques sélectionnables par utilisateur destinées à être affichées dans la GUI, les options/caractéristiques affichées dépendant du type d'utilisateur. Un moteur de manipulation reçoit une entrée utilisateur et détermine des opérations à réaliser, la détermination étant basée sur le type d'utilisateur. BRÈVE DESCRIPTION DES DESSINS La présente invention est illustrée au moyen d'un exemple et non pas à titre de limitation sur les figures des dessins annexés sur lesquels des index de référence identiques se rapportent à des éléments similaires, et parmi ces dessins: la figure 1 représente un procédé d'édition audio de l'art antérieur; la figure 2 représente une vue globale d'un mode de réalisation de la présente invention; la figure 3 représente de manière davantage détaillée les modules de logiciel selon un mode de réalisation de la présente invention; la figure 4 représente une structure de données qui définit une piste selon un mode de réalisation de la présente invention; la figure 5A à 5E représentent diverses opérations d'édition réalisées sur une piste de données audio; la figure 6 représente un exemple de l'interface utilisateur graphique qui peut être utilisée pour réaliser une édition; la figure 7 représente un mode de réalisation d'un système qui génère des interfaces configurables par utilisateur selon les enseignements de la présente invention la figure 8 représente un exemple d'une interface utilisateur graphique pour un type différent d'utilisateur; et la figure 9 représente un autre exemple d'une interface utilisateur graphique pour un utilisateur particulier. DESCRIPTION DETAILLÉE DU MODE DE RÉALISATION PRÉFÉRÉ La présente invention est un procédé et un appareil permettant de générer une interface configurable par utilisateur. Dans la description détaillée qui suit, de nombreux détails spécifiques sont mis en exergue afin d'assurer une compréhension complète de la présente invention. Il apparaîtra à l'homme de l'art que ces détails spécifiques n'ont pas besoin d'être utilisés pour la mise en oeuvre pratique de la présente invention. Dans d'autres cas, des structures, des interfaces et des processus bien connus n'ont pas été présentés en détail afin de ne pas obscurcir de façon non nécessaire la présente invention. La figure 2 représente une vue globale d'un mode de réalisation de la présente invention. Bien que les sections qui suivent décrivent un processus d'édition audio, la même technique peut être appliquée avec succès à un processus d'édition vidéo. Comme représenté, le système selon la présente invention comprend au moins une station d'édition couplée à une pluralité de stations à distance (stations à distance 1 à N). Les stations a distance 1 à N contiennent des données audio/vidéo stockées sous forme numérisée sur un ou plusieurs disques de stockage. Conformément à ce mode de réalisation de la présente invention, un ingénieur du son peut éditer les données numérisées qui résident sur l'une quelconque des stations à distance 1 à N depuis un unique emplacement, à savoir une station d'édition 200. L'ingénieur du son peut également éditer les données numérisées sur les stations à distance 1 à N par exemple au moyen d'une copie d'information audio depuis une piste sur une station et au moyen du collage de l'information audio coupée sur une piste sur une autre station. Les opérations d'édition sur des stations à distance sont décrites de manière davantage détaillée ci-après. La station d'édition 200 peut être un ordinateur personnel (PC) ou n'importe quel autre type de système permettant d'afficher une application graphique, d'accepter une entrée via l'application graphique et de communiquer l'entrée jusqu'à un emplacement à distance. Les stations à distance 1 à N peuvent également comprendre un PC ou une station de stockage/édition d'information audio/vidéo privée telle qu'un système de lecteur enregistreur de Sony Corporation (marque déposée). Les stations a distance 1 à N peuvent inclure des fentes pour de multiples disques amovibles tels que des disques lomega Jaz, ce qui augmente le stockage disponible pour la station à distance et ce qui permet de déplacer aisément les données stockées depuis un emplacement à distance jusqu'à un autre. La figure 3 représente les modules de logiciel selon un mode de réalisation de la présente invention. La station d'édition 200 inclut une application d'édition 302, des bibliothèques de liaisons dynamiques (DLL) 304 et un mécanisme d'appel de procédure à distance (RPC) 306. L'application d'édition 302 permet à l'ingénieur du son de réaliser des fonctions d'édition via une interface utilisateur graphique (GUI). Le mécanisme de RPC 306 constitue une liaison de communication entre la station d'édition et les stations à distance 1 à N (au vu de la figure 2). Selon un mode de réalisation de la présente invention, le mécanisme de RPC 306 est un mécanisme de RPC basé sur Windows NT de Microsoft (marque déposée). D'autres mécanismes de RPC ou d'autres mécanismes de réseau pour une communication à distance peuvent également être utilisés. La figure 3 représente également un exemple des modules de logiciel sur une station à distance présentée à titre d'exemple selon un mode de réalisation de la présente invention. La station à distance présentée à titre d'exemple comprend un mécanisme de RPC 308 (qui correspond au mécanisme de RPC 306 sur la station d'édition 300), des DLL 310 et un mécanisme de pilotage 312 qui interagit avec un système de traitement de signal numérique (DSP) 314. Un ingénieur du son interagit avec les stations à distance 1 à N depuis la station d'édition 200 via une GUI, les fonctions spécifiées via la GUI sont communiquées entre la station d'édition 200 et les stations à distance 1 à N via les mécanismes de RPC 306 et 308, et les DLL 310 et le système DSP réalisent tout le traitement nécessaire pour la mise en oeuvre des fonctions spécifiées. La figure 4 représente la structure de données d'une piste audio sur une station à distance présentée a titre d'exemple selon un mode de réalisation de la présente invention. Une piste audio est une représentation statique d'une information audio qui spécifie l'emplacement des données audio sur un disque, des données organisationnelles nécessaires pour lire correctement les données audio ainsi que d'une certaine variété d'autres paramètres associés aux données audio. Conformément a un mode de réalisation de la présente invention, les divers paramètres associés a des données audio sont chacun spécifiés dans une liste. Les diverses listes représentées sur la figure 4 correspondent en conséquence à une unique piste audio. Cette piste est représentée par une structure de données qui lie toutes les listes ensemble d'une façon logique. En utilisant une unique structure de données pour lier toutes les listes ensemble, un mode de réalisation de la présente invention permet à toutes les données associées à une piste particulière d'information audio d'être éditées collectivement par une interface d'édition commune. Par conséquent, par exemple, si un ingénieur du son décide d'éditer une partie d'une piste audio, toutes les listes associées à cette partie de la piste audio peuvent être éditées simultanément à la différence des systèmes de l'art intérieur dans lesquels divers aspects de la piste peuvent avoir à être édités séparément. Le mécanisme qui réalise des éditions sur la structure de données sous forme de piste de la figure 4 met en jeu plusieurs composants. Selon un mode de réalisation, les composants sont mis en oeuvre en tant que classes C++. Les composants primaires sont: des pistes, des listes d'événements et des événements. Chacun de ces composants est représenté sur la figure 4 et est décrit de manière davantage détaillée ci-après. Bien que la description qui suit suppose une mise en oeuvre C++, la même fonctionnalité ou une fonctionnalité similaire peut être mise en oeuvre dans d'autres environnements de programmation. Une "piste" est un objet public qui est utilisé par des applications audio afin de représenter des trains statiques d'information audio ainsi que d'autres données sur une base temporelle. Une piste est mise en oeuvre en tant qu'objet nommé (c'est-à-dire qu'elle comporte un nom de chaîne) qui maintient une collection de listes d'événements (comme décrit ci-après). Une piste expose une interface d'édition qui est appliquée à chaque liste d'événements. Conformément à un mode de réalisation, une piste maintient au moins une liste d'événements, à savoir la liste de sons (voir figure 4). "Des listes d'événements" sont des structures de données liées doublement qui maintiennent deux types d'événements de base. L'événement par défaut est appelé un événement de "silence" et l'autre événement est appelé un événement de "non silence". Il y a une liste d'événements séparée pour chaque type de combinaison d'événements de silence/non silence. Par exemple, comme représenté sur la figure 4, des cercles pleins suivant l'axe des temps de l'information audio représentent la survenue d'un son tandis que des cercles non pleins représentent un silence. D'autres listes sont également envisagées. Par exemple, comme représenté sur la figure 4, la liste de gains représente la grandeur du gain qui est appliqué sur des parties particulières d'une piste audio. Par exemple, le cercle plein indique qu'une certaine valeur scalaire de gain doit -être appliquée tandis que le cercle non plein représente qu'un gain unitaire doit être appliqué. La figure 4 représente également "d'autres listes", qui, comme il apparaît maintenant à l'homme de l'art, peuvent inclure une certaine variété de paramètres incluant des paramètres rapportés à une information vidéo ou à d'autres opérations d'édition. Chaque type d'événement maintient au minimum une longueur mesurée en terme d'échantillons et en terme d'autres données nécessaires pour définir le comportement d'événement. Selon un mode de réalisation, virtuellement la totalité du comportement d'édition des listes d'événements est mise en oeuvre selon une classe C++. Chaque type d'événement maintient deux fonctions virtuelles importantes: SlideStart (...) et SlideEnd (...). Lorsque de nouveaux événements de non silence sont créés, chaque événement doit mettre en oeuvre à nouveau ces fonctions. Ceci est dû au fait que lorsqu'un temps de début et/ou un temps de fin d'une opération d'édition ne correspondent pas au début d'un événement, un "raccordement" doit être créé. Ceci est réalisé en copiant l'événement approprié en "faisant glisser" la fin de l'événement de source puis en "faisant glisser" le début de l'événement copié. Ce mécanisme de glissement est représenté de manière davantage détaillée ci-après (voir figure 5C ci- après). Les listes d'événements sont des structures de données basées sur le temps qui contiennent des événements liés, chaque événement maintenant au minimum une longueur mesurée en terme d'échantillons. La somme des longueurs de tous les événements plus du décalage de début (comme expliqué de manière davantage détaillée ci-après) est égale à la longueur de la liste d'événements. Par défaut, le premier événement commence au temps absolu de zero échantillon sauf si un décalage de début est présent, auquel cas le premier événement commence à la valeur du décalage de début. Le temps absolu (mesuré en échantillons) au début d'un événement est mesuré en additionnant les longueurs de tous les événements le précédant y compris le décalage de début. Dans le contexte de la présente discussion, les pistes et les listes d'événements sont utilisées de façon interchangeable. Les pistes représentent de multiples listes d'événements. Une liste d'événements de travail est une liste qui contient les événements qui sont constitués afin de modéliser un type spécifique de comportement audio. Les listes d'événements de travail sont initialement créées avec un événement de silence très important. Une fois que la liste d'événements de travail a été créée, des opérations d'édition peuvent lui être appliquées. Des uniques événements peuvent être additionnés à la liste en appelant une fonction d'addition Add (...) appropriée. En outre, selon un mode de réalisation de la présente invention, six opérations d'édition primitives peuvent être appliquées. Ce sont: Clear (, soit Remise à zéro 0 Cut (, soit Couper ( Copy 0, soit Copier O Paste (, soit Coller 0 Insert (), soit Insérer () Insert 0 (space), soit Insérer O (espace). Des pistes, des listes d'événements et de quelconques autres objets qui modèlent l'édition utilisent les termes mentionnés ci-avant lors de la définition d'une interface d'édition. Les opérations d'édition, lorsqu'elles s'appliquent à des listes d'événements, font l'objet d'une discussion ci-après et sont représentées sur les figures 5A à 5E. Selon un autre mode de réalisation de la présente invention, d'autres opérations d'édition peuvent également être réalisées. "Clear" remplace une section d'événements par du silence sans affecter les instants des événements après l'instant de fin. Clear est de fait une opération de sur-écriture. L'opération d'édition "Clear" est représentée sur la figure 5A. Des opérations "Paste" collent une liste de source dans une liste de destination. Les instants de début et de fin du collage sont déterminés par la liste de source. Les opérations de collage sur-écrivent, et il s'ensuit que les instants des événements après le temps de fin restent inchangés, comme représenté sur la figure 5B. Les opérations "Insert" insèrent une liste de source dans une liste de destination. Le point d'insertion est déterminé par l'instant de début de la liste de source. Les instants de tous les événements au niveau du point d'insertion et après ce point d'insertion sont décalés de la longueur de la liste de source. Ceci est décrit ci-après en relation avec la figure 5C. "Insert space" insère simplement une liste d'événements vierge d'une longueur spécifiée en lieu et place d'une liste de source dans une destination. "Cut" enlève une section d'événements d'une liste d'événements. Tous les événements après l'instant de fin sont décalés plus tôt temporellement de la longueur de l'élément coupé, comme représenté sur la figure 5D. Pour finir, les opérations "Copy" copient une section d'une liste d'événements tandis que la liste de source reste non affectée, comme représenté sur la figure 5E. La figure 6 représente un exemple d'un écran de GUI qui doit être généré par une application d'édition 302 au niveau d'une station d'édition 200. Cet écran de GUI permet à l'ingénieur du son de spécifier une plage pour des fonctions d'édition à réaliser sur les données audio. Par exemple, l'écran sur la figure 6 représente un affichage de sept pistes séparées (FXL, FXC, FXR, FXS, FoleyL, FoleyC et FoleyR). Ces sept pistes peuvent résider sur une unique station ou sur des stations séparées sur un réseau. Cette capacité qu'a un ingénieur du son d'accéder à de multiples stations sur un réseau pour une édition simultanée à partir d'un unique emplacement à distance représente une avancée significative sur les procédés de l'art intérieur d'édition d'information audio/vidéo. Selon un mode de réalisation de la présente invention, I'ingénieur du son peut réaliser de multiples opérations d'édition sur autant de stations à distance qu'il souhaite, ce qui confère à l'ingénieur du son la flexibilité d'éditer une quantité importante d'information audio de façon très simple. Par conséquent, par exemple, un ingénieur du son peut réaliser l'une quelconque des opérations d'édition décrites ci-avant au niveau de la partie suréclairée de l'écran. La partie suréclairée correspond à une partie de données audio sur de multiples pistes de données audio, chaque piste comprenant de multiples listes. La représentation visuelle de l'information audio procure à l'ingénieur du son une grande flexibilité pour spécifier des fonctions d'édition. Par exemple, I'ingénieur du son peut suréclairer une partie prédéterminée de l'écran et peut spécifier des fonctions d'édition à réaliser sur la totalité de la zone suréclairée. Cette zone suréclairée, comme représenté sur la figure 6, peut inclure à la fois des parties ombrées et non ombrées de l'écran. Les parties ombrées indiquent les parties audio actives (de non silence) de chaque piste tandis que les espaces vierges indiquent un silence. Lorsque l'ingénieur du son spécifie une fonction d'édition, la fonction est appliquée sur les pistes, ce qui permet à l'utilisateur d'éditer les multiples pistes simultanément. De façon davantage significative, ces pistes peuvent résider sur des machines séparées sur le réseau en opposition avec l'art intérieur dans lequel une station d'édition peut seulement éditer des données qui résident sur une station locale. Cette capacité à réaliser une édition de données audio/vidéo numérisées à partir d'une unique station d'édition sur un réseau procure des avantages pratiques significatifs qui vont au-delà de simplement permettre la réalisation plus efficace du processus. Dans une installation d'édition de film courante, par exemple, divers studios d'édition peuvent chacun contenir de multiples stations d'édition afin d'éditer différentes parties de données audio/vidéo, la sortie de toutes les stations d'édition étant entrée dans une console de mixage ou mélange. Dans l'éventualité o une machine est réassignée à un studio différent, la totalité de la station d'édition doit être déplacée physiquement jusqu'au nouvel emplacement. A l'opposé, selon un mode de réalisation de la présente invention, les stations physiques à distance n'ont pas à être déplacées. En lieu et place, les stations à distance peuvent résider en n'importe quel emplacement et chaque studio peut simplement se voir assigner un jeu prédéterminé de stations à distance. De cette manière, le nombre de stations à distance assignées a un studio peut varier sur une base quotidienne ou même dans l'heure sans problème significatif. Selon un autre mode de réalisation, la structure des données peut être utilisée afin de supporter une certaine variété de GUI qui sont personnalisées pour différents types d'utilisateurs. Par exemple, dans l'industrie du cinéma, différents individus travaillent sur la production du son, la composition musicale, l'édition de musique et l'édition du son. Le travail réalisé par les différents individus met en jeu un accès à la totalité de la structure de données ou seulement à une partie de celle- ci, dont un exemple est représenté par la figure 4. Cependant, ces différents individus sont habitués à des interfaces utilisateur différentes. Par exemple, les personnes de la production du son ou de la composition musicale travaillent avec des portées, des mesures et des battements afin d'identifier les parties particulières auxquelles une opération se rapporte. Les éditeurs de son incluant des mélangeurs ou mixeurs travaillent avec un code SMPTE. De façon similaire, si une information audio pour des applications non vidéo a été traitée dans ce système, les différentes parties de l'information audio peuvent être identifiées par un code MIDI. Selon cet autre mode de réalisation, le système inclut en outre un moteur de description de données, tel que représenté sur la figure 7. Par report a la figure 7, la GUI 705 qui contient les données A/V est créée par le moteur de description de données 710 en accédant à la base de données A/V 715. Le moteur de description de données 710 peut être mis en oeuvre sous forme de logiciels destinés à être déroulés sur des processeurs existants ou sur d'autres processeurs. Selon une variante, il peut être mis en oeuvre dans un système dédié constitué par des composants matériels ou par des logiciels. La GUI générée dépend du type d'utilisateur. Par conséquent, par exemple, I'utilisateur peut initialement se voir demander par le moteur de description de données d'identifier le type de GUI souhaité, par exemple édition du son, production du son, etc... Selon une variante, le système peut mettre en oeuvre un type par défaut de GUI sur la base de la connexion ou de tout autre identification utilisateur. Le moteur de description de données accède à la base de données A/V 715 et le générateur d'affichage affiche les données dignes d'intérêt selon une représentation configurée pour le type d'utilisateur. Ceci est représenté graphiquement sur les figures 6 et 8. Comme noté précédemment, la figure 6 est une représentation d'une GUI configurée pour un éditeur de son. La figure 8 est une représentation d'une GUI pour un dispositif de duplication. Il doit être noté que les données provenant des différentes pistes sont représentées graphiquement d'une manière différente. Par exemple, par report à la figure 6, I'éditeur de son est constitué en tant que représentation graphique des données audio (par exemple la zone 655) en plus de la production de l'identification de l'information audio particulière présentement accédée et représentée dans chacune des pistes représentées. L'affichage du dispositif de duplication prévoit également l'identification 805 des données audio accédées; cependant, lorsque les opérations d'édition ne sont pas réalisées au niveau d'une station de duplication, la représentation graphique des données audio n'est pas assurée. De façon similaire, la duplication utilise fréquemment des décalages afin de décaler des pistes différentes les unes par rapport aux autres (par exemple pour le mixage ou mélange); cependant, les décalages ne sont typiquement pas utilisés lors du processus d'édition. Par conséquent, des zones de décalage sont prévues (par exemple en 810) dans la GUI de la figure 8 et non pas dans la GUI de la figure 6. Les représentations peuvent être pré-générées et stockées par exemple dans le fichier de données de référence 735 ou dans n'importe quel autre support sous forme de mémoire ou de stockage. La représentation peut être stockée en tant que données descriptives ou en tant que code exécutable (par exemple en Java ou similaire). Il doit être noté qu'il peut y avoir une certaine communauté de représentation. Par exemple, les codes temporels représentant des points d'entrée, des points de sortie etc... (par exemple 666 à 690 et 830 a 836) peuvent être les mêmes, en fonction du type d'utilisateur. En outre, le constructeur de menu 725 (figure 7) génère les caractéristiques/options/opérations sélectionnables par utilisateur pour le type particulier de GUI. Comme en ce qui concerne les représentations de données, les menus peuvent être prégénérés et stockés par exemple dans le fichier de données de référence 735 ou dans n'importe quel autre support sous forme de mémoire ou de stockage. La représentation peut être stockée en tant que données descriptives ou en tant que code exécutable (par exemple en Java ou similaire). Des exemples des différentes caractéristiques/options/opérations sélectionnables par utilisateur peuvent être vus par report à nouveau aux figures 6 et 8. Dans la GUI du dispositif de duplication, plusieurs options telles que sécurité "s" 812, enregistrement "R" 814, entrée "1" 816, solo "S" 818 et silence "M" 820 peuvent être envisagées. Ces options sont mises en oeuvre en tant que boutons de telle sorte que, lorsque l'utilisateur réalise une sélection par exemple en plaçant le curseur sur la zone du bouton et en "cliquant" la souris/bille traçante, la fonction soit validée. Par exemple, le bouton de sécurité 812 met en oeuvre un mécanisme de protection d'écriture sur la totalité de la piste. Le bouton d'enregistrement 814 initie immédiatement l'enregistrement de l'entrée sur la piste sélectionnée. Le bouton d'entrée 816 permet à l'utilisateur d'entendre ce qu'il y a au niveau de l'entrée (par opposition à ce qu'il y a au niveau de la sortie). Le bouton de mise au silence 820 met au silence la piste sélectionnée et le bouton de solo 818 met au silence toutes les pistes à l'exception de la piste sélectionnée. Dans la GUI d'édition de la figure 6, des fonctions similaires sont assurées mais il y en a certaines qui sont mises en oeuvre différemment afin de réaliser une adaptation à la façon dont différents utilisateurs opèrent. Comme représenté, des boutons sont prévus pour les fonctions de solo 678, de mise au silence 680, d'entrée 682 et d'enregistrement 684. Cependant, à la différence d'une application de duplication, une application d'édition met en oeuvre une bande qui est basée sur un modèle d'enregistrement à multiples pistes. Par conséquent, si un utilisateur sélectionne la fonction d'enregistrement, le bouton clignotera pour indiquer une attente pour initier un enregistrement et se modifiera selon une couleur continue afin d'indiquer lorsqu'un enregistrement est initié,comme commandé par l'utilisateur qui sélectionne un bouton d'enregistrement maître (par exemple le bouton 691) sur l'affichage. Une fois que l'enregistrement maître est sélectionné, des boutons d'enregistrement de piste additionnels peuvent être sélectionnés et immédiatement validés. En outre, si l'enregistrement maître est à nouveau sélectionné afin de couper la fonction d'enregistrement maître, les boutons d'enregistrement de piste clignoteront à nouveau pour indiquer une attente pour un état d'enregistrement. Des fonctions identiques sont également assurées telles que les fonctions de commande de bande, par exemple, avance rapide, avance inverse, lecture, arrêt etc... (690 et 840) et qu'un défilement conformément à un code temporel (692 et 842). En outre, certaines fonctions assurées sont seulement trouvées dans des types particuliers de GUI. Par exemple, les boutons de sélection de piste programmables 844 et les boutons de sélection de toutes les pistes 845 ou d'aucune piste 846 sont très utiles dans l'application de duplication dans laquelle l'utilisateur est en train de manipuler de nombreuses pistes différentes à la fois. En outre, graphiquement, les fonctions peuvent être représentées différemment de ce qui est défini par le constructeur de menu. Par exemple, la valeur de gain est représentée en tant qu'icône en coulisseau dans la GUI d'édition et en tant que valeur numérique dans la GUI de duplication. La sélection de la colonne ou de l'icône de gain dans la GUI appropriée conduira à l'affichage de la fenêtre de progression de gain comme représenté sur la figure 9, ce qui permet à I'utilisateur de régler le gain en utilisant un coulisseau graphique. Il doit être noté que la figure 9 représente en totalité un autre mode de réalisation d'une GUI de duplication qui peut être configurée par l'utilisateur. Dans cette illustration, des pistes qui identifient séparément une entrée et une sortie sont utilisées afin de simplifier l'information affichée. D'autres modes de réalisation sont également envisagés. Une fois que les données et les fonctions sélectionnables par l'utilisateur sont affichées, l'utilisateur peut appliquer une entrée sur le système afin de réaliser certaines tâches. L'entrée de l'utilisateur est de préférence traitée par I'intermédiaire du moteur de manipulation (730, figure 7) qui interprète l'entrée et qui génère des instructions qui sont comprises par le système. L'avantage est que l'utilisateur peut utiliser la nomenclature particulière ou le "langage" particulier typiquement utilisé et que le système comprendra ce qui doit être réalisé et comment réaliser la tâche. Par conséquent, certaines fonctions sont uniques pour un type particulier d'utilisateur et certaines sont communes bien que référencées différemment. Par exemple, lors de la production du son, une opération est appelée "basculement", lors d'une édition de musique, la même opération est appelée "couplet" et lors d'une édition du son, la même opération est appelée "prise de son". Les trois vocables se réfèrent a l'opération de cadencement temporel depuis un point déterminé afin d'enregistrer de multiples versions du même son. Par conséquent, I'opération d'enregistrement des données sera la même même si elle est appelée différemment par différents types d'utilisateurs. Le moteur de manipulation peut être mis en oeuvre selon une certaine variété de façons. Selon un mode de réalisation, un dictionnaire est construit et stocké par exemple sur un dispositif de stockage 735 destiné à contenir des fonctions utilisateur possibles et des fonctions internes correspondantes. Le moteur de manipulation peut alors rechercher dans le dictionnaire la fonction particulière afin de déterminer la fonction interne à exécuter. Comme on peut le voir, la présente illustration peut être étendue au- delà du domaine audio à des exemples du domaine vidéo ou à d'autres types d'utilisateurs audio ou vidéo. Par conséquent, on envisage que le même système puisse supporter une large variété d'utilisateurs sans avoir à prévoir des composants matériels utilisateur spécialisés pour un type particulier d'utilisateur. Par conséquent, un procédé et un appareil permettant de générer une interface utilisateur graphique configurable par utilisateur sont décrits. Ces agencements et procédés spécifiques décrits ici sont simplement illustratifs des principes de la présente invention. De nombreuses modifications au niveau de la forme et des détails peuvent être apportées par l'homme de l'art sans que l'on s'écarte du cadre de la présente invention. Bien que la présente invention ait été présentée en relation avec un mode de réalisation particulier préféré, celle-ci n'est pas considérée comme étant ainsi limitée. La présente invention est limitée seulement par le cadre des revendications annexées. REVENDICATION 1. Système caractérisé en ce qu'il comprend: une interface utilisateur graphique (GUI) (705) un système de fichiers audio/vidéo (A/V) (715) comprenant des données A/V; et un moteur de description de données (710) couplé entre la GUI et le système de fichiers AVN, ledit moteur de description de données comprenant: un générateur d'affichage (720) configuré pour appliquer des données A/V sous une forme pour un affichage dans la GUI pour un type particulier d'utilisateur; un constructeur de menu (725) configuré pour générer des options/caractéristiques sélectionnables par utilisateur pour un affichage dans la GUI, les options/caractéristiques sélectionnables par utilisateur générées dépendant du type particulier d'utilisateur; et un moteur de manipulation (730) configuré pour recevoir une entrée utilisateur et pour déterminer une opération a réaliser, la détermination de l'opération à réaliser dépendant du type particulier d'utilisateur.