WO2008081415A2 - Media file server - Google Patents

Media file server Download PDF

Info

Publication number
WO2008081415A2
WO2008081415A2 PCT/IB2007/055405 IB2007055405W WO2008081415A2 WO 2008081415 A2 WO2008081415 A2 WO 2008081415A2 IB 2007055405 W IB2007055405 W IB 2007055405W WO 2008081415 A2 WO2008081415 A2 WO 2008081415A2
Authority
WO
WIPO (PCT)
Prior art keywords
media file
media
catalog
playlist
storage
Prior art date
Application number
PCT/IB2007/055405
Other languages
French (fr)
Other versions
WO2008081415A3 (en
Inventor
Thibaut Lamadon
John Watlington
Original Assignee
France Telecom
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by France Telecom filed Critical France Telecom
Publication of WO2008081415A2 publication Critical patent/WO2008081415A2/en
Publication of WO2008081415A3 publication Critical patent/WO2008081415A3/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
    • G06F16/43Querying
    • G06F16/438Presentation of query results
    • G06F16/4387Presentation of query results by the use of playlists
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
    • G06F16/41Indexing; Data structures therefor; Storage structures
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/40Information retrieval; Database structures therefor; File system structures therefor of multimedia data, e.g. slideshows comprising image and additional audio data
    • G06F16/48Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually

Definitions

  • FIELD OFTHEFBESENTSYSTEM The present devic e relates in general to the management of media files stored in one or more data bases, and more specifically to the retrieval of such media file s se Ie c te d fora playlist when these files are relocated or moved.
  • a media item Le. an audio, video, text, or any other media type, is generally defined by both its meta data and its c ontent.
  • the meta data generally refers to the information on the media fie, Le. its title, artist, album name, director (fora movie), duration, bit perminute, ...
  • the content is the data that is retrieved to be viewed and/ or listened to.
  • a computerora media player for example, one may have access to different sources and libraries over which the media items are distributed.
  • the media file contents are generally played or rendered through a playback device (or media rendering device).
  • a playback device or media rendering device.
  • the media rendering device may be a personal computer, an MP3/MP4 player, a DVD player, orany other suitable device that can play media files.
  • the different source Io cations may comprise the playback device storage.
  • Tb play a list of media files, one may regroup a selection of such files in a playlist.
  • a playlist is a common tool adopted by the software programs from media rendering devices intended to organize and control media files. Such playlists may be defined, stored, and selected to either run media files in sequence or, if a random playlist function is selected, in a random order.
  • a playlist may also be described as a sequence of selected objects to be rendered. The function of a playlist is generally to identify the objects it refers to so that said objects can be communicated to the rendering device according to the ir o rd e r in the playlist.
  • Playlist are generally organized in a table associating the media file metadata to an address from which the media file content can be retrieved for an immediate or later play. For different reasons one may need to move files from one source to another. Furthermore, the same file maybe located on two different storage locations. With known playlist architectures, whenever a file is moved to or duplicated on a different source, the playlist may be broken as the address in the playlist is not updated. This may result in a corrupted playlist, that will cause the media rendering device to skip the file or simply stop playing the files. In other words if the playlist is generated with the initial content of a media file library, any further reorganization of the library content (e.g. media files moved to different addresses) may result in a broken playlist that cannot be rendered on a playback device.
  • any further reorganization of the library content e.g. media files moved to different addresses
  • SUV-MAKT OFTHE FBESBNTSYSTEM It is an object of the present system to address a device and a method to overcome disadvantages and/ormake improvements in the prior art.
  • the present system includes a method and system for generating a reliable playlist to be rendered on a playback device. Accordingly, the present system relates to a method to manage media files, each media file being characterized by a metadata and a data content to be rendered, said method c omprising the steps of:
  • said p Ia ylist comprising at least foreach selected media file entry its unique identifier, and, for at least part of each selected media file entry of said playlist: -searching its unique id e ntifie r in the catalog,
  • the problem of updating the address of a media file is transferred to the step of generating the catalog.
  • a regular update of the catalog each time an address is changed (new file, new library storing media files, removal of a file, removal of a library) or a periodic update ensures that the unique identifier points to the right address wherein the media file content is sto re d .
  • the step of computing the unique identifier is furthe r c a rrie d out taking into account the data content of the media fie.
  • the identifier, or hash as explained later on, may be generating using different data identifying a media fie, provided the hash is unique to said media fie.
  • the media files are stored in a plurality of storage libraries, and the step of generating a catalog furthe r c o mp rise s the step of retrieving the list o f sto ra g e libraries the media files are stored in.
  • the step of generating the catalog further comprising the steps of associating a library identifier for each storage lib ra ry, a nd , a sso c ia ting for each media file entry the library identifier where in the contentdata forthe media file canbe retrieved.
  • the step of generating the catalog further comprises the step of collecting the type of media file for each media file entry.
  • the media files are stored in a plurality of storage libraries, a triggering event forthe step ofgenerating the catalog being atleastone of:
  • the step ofgenerating the catalog is carried out forthe media files and storage libraries that caused the triggering event.
  • the present system also relates to system to manage media files, each media file being characterized by a metadata and a data content to be rendered, said system comprising:
  • - a medium storage to store a catalog of media file entries, each media file entry corresponding to a media file and comprising: -the media file metadata of said media file,
  • a playlist processor operationally coupled to the medium storage and arranged to generate a playlist of media files selected in the catalog, said playlist comprising at least foreach selected media file its unique identifier, wherein the data content of each selected media file of the playlist is retrieved by searching in the catalog the up-to-date address corresponding to its unique id e ntifie r.
  • the media files are stored in a plurality of storage libraries
  • the system further comprises a catalog processor opera tively coupled to the medium storage, said processorbeing arranged to:
  • the catalog processor is further arranged to retrieve the data content of each selected media file of the playlist by searching in the catalog the up-to-date address corresponding to the unique identifier.
  • each library is associated with a library identifier, and wherein the catalog processorisfurtherarranged to:
  • the media files are stored in a plurality of storage libraries, the system comprising a catalog processor arranged to generate the catalog upon the occurrence of a triggering event, said triggering event be ing at least one of:
  • the catalog processor is further arranged to generate the catalog forthe media files and storage libraries that caused the triggering event.
  • the present system relates to an application embodied on a computer readable medium arranged to manage media files, the application co mp rising :
  • - c ompute a unique identifier at least on part of said media fie metadata, -a portion to generate a p Ia ylist from media fie e ntrie s se Ie c te d in said catalog, said playlist comprising at least for each selected media fie entry its unique id e ntifie r, and, for at least part of each selected media fie entry of said playlist a portion to:
  • FlG.1 illustrates one embodiment of the system to generate an a playlist according to the p re se nt syste m ;
  • FlG.2 illustra te s o ne embodiment of a flowchart related to the collecting of the media items on different servers, in accordance with one embodiment of the method according to the p re se nt syste m ;
  • FlG.3 illustrates a detailed flowchart of the parsing step of FIG.2;
  • FIG.4 illustrates a flowchart related to a playlist generation in the system according to the present system.
  • FIG.5 illustrates a device in accordance with an embodiment of the present system.
  • a system 100 as shown in FlG.1 is provided for generating a playlist.
  • the system 100 includes a medium storage 110, a media file manipulation portion 120, a playlist generation portion 125 and a playback device 130.
  • each media file is characterized by a metadata and a data content.
  • the data content may include audio content, video content, audio/visual content, image content, textual content, and/or other content that may be rendered to a user.
  • the metadata may include artist's name, author's name, album title, rendering length of a media file content, its year of production, genre, b e a ts-p e r-minute , tone, tempo, ranking according to a user's taste, and/or any other characteristics that may be utilized to suitably describe characteristics of the media file.
  • the data content of a media file is associated as explained later on with an address or a path indicating where the content can be retrieved. This address may be provided e .g . in the fo rm o f a URL(unifo rm re so urc e Io c ato r) a ddre ss.
  • the medium storage 110 is an indexing storage that stores some available information (including the metadata) for each media file collected on a plurality o f c o nte nt lib ra rie s 1 to N - with N a n inte gergreater the n ⁇ -asexpla ine d Ia te r on.
  • the available information is stored in the form of a catalog of media file entries. In other words, the catalog regroups in a list information on the media files available on the different libraries 1 to N accessible to the system according to the present system.
  • the file manipulation portion 120 is arranged to generate the catalog of media file entries stored on the medium storage 110.
  • the media file manipulation portion 120 is therefore operatively coupled to the medium storage 110.
  • the media file manipulation portion 120 may comprise a processor called here aftera catalog processor.
  • the media file manipulation portion 120 is thus arranged to access the different storage libraries 1 to N to enable the collection and storage on the medium storage 110 of the available information for each media item.
  • Each entry in the catalog correspond to a media item.
  • Tb collect the information
  • the media file manipulation portion 120 is connected to the d iffe re nt c o nte nt lib ra rie s by any suitable transfer protocol as explained later on.
  • the content libraries may be located on remote sources associated to servers.
  • One or more content libraries may also be located on one or more local storages linked to, orpartof the indexing storage 110.
  • the media file manipulation portion 120 further stores an up-to-date address for the data content associated to each media file entry.
  • the media file manipulation portion 120 is further arranged to allow the retrieval of said data content for each entry in the catalog. The retrieval is based on the media file up-to-date address stored with e a c h e ntry in the c atalo g .
  • the media file manipulation portion 120 is also arranged to generate a unique identifierforeach media item, based on the collected media item information and/or its corresponding data content as explained lateron.
  • the system according to the present system furthe r c o mp rise s a playlist processor 125 arranged to generate a playlist of media files, eitherusing a user input through a use r inp ut inte rfa c e - no shown in FlG.1 - or any suitable playlist generation method.
  • the available media items for creation of the playlist are the media files corresponding to the entries in the catalog stored in the medium storage 110.
  • the playlist processor 125 is therefore operatively coupled to the media file manipulation portion 120, and consequently to the medium storage 110.
  • the playlist processor 125 is arranged, when generating a playlist of media files, to include in said playlist at least the unique identifier of each selected media file.
  • the playlist Afterthe playlist is generated, it may be saved (on medium storage 110 or a separate storage) for later use.
  • the selected media items may also be rendered by the media rendering device 130, sequentially or randomly, after theirdata content is retrieved by the media file manipulation portion 120 through their unique identifier in the playlist. Indeed, the unique identifier allows the media file manipulation portion 120 to point in the catalog to an up-to-date address for the data content.
  • the manipulation portion 120 may retrieve in one of the storage libraries the data content and forward it to the rendering device 130.
  • the playlists are associated to the catalog.
  • the catalog indexes (through the retrieval of the available data on the different libraries) all the media files available to the system.
  • a unique id e ntifie r is g e ne ra te d that allows to point to said media file in the system according to the present system.
  • the user may be the ownerof a 11 the me d ia file s.
  • r c a n inc re a se the numb e r o f file s he / she ha s a c c e ss to by adding more files to one of more of the storage libraries, o r sub sc rib ing to online storage libraries.
  • the user may also acquire additional media files through purchasing files on the internet through e.g. his/her laptop, or download available video files through pod casting.
  • the medium storage 110 along the media file manipulation portion 120 form a central server in the system according to the present system, also called the indexing server.
  • This indexing server will collect data available on the different storage libraries as explained here after.
  • the indexing storage 110, the media file manipulation portion 120, the playlist processor 125 and the media rendering device 130 may all be part of the same device, e.g. a server or a computer. Each of these different elements may also be part of separate devices, or some of them may be regrouped in the same device.
  • the medium storage 110 and the media file manipulation portion 120 may be comprised within a first device like a server or a personal computer while the media rendering device 130 and the playlist processor 125 may be part of a second device, like a portable media player, e.g. an MP3 player (docketed on a suitable port of the first device).
  • the second device is operatively coupled to the first so that the second device, after generating the playlist based on the catalog entries, renders the selected media files as their unique identifier points to an up-to-date address in the catalog.
  • the user can in the system according to the present system access through the catalog to a plurality of storage libraries, as each entry in the catalog comprises an up-to-date address for the media item.
  • the address, also called here after the location, of a media file on one of the storage libraries is what will allow the system to get to the data content of an identified media fie. Tb allow such a retrieval, the address allows access to resources on different ma chines/ servers, using different protocols.
  • the address to retrieve the data content includes the transferprotocolthat is used to access said data content.
  • the location may be written as follows: ⁇ protocol>:// ⁇ serve r>/ ⁇ resource local id > wherein:
  • Table 1 location description in the system according to the present system Tb access a file singer.mp3 on a local storage nfs, and stored in the directory John/ storage/music/pop, the location may be the following: nfs://localhost/home/john/storage/music/pop/singer.mp3 To access a fie movie.avi over the internet using rtps (data distribution se rvic e ) to a c c e ss the www.cc ccom web site , the Io c a tio n ma y b e the fo Uo wing : rtps:// www. c cc.c om/mo vie /movie.avi
  • Tb access a song with an ID 1235 in a user collection on a server quintessence using DAAP (Digital Audio Access Protocol from AppleTM), the address may be: lune s:// quinte sse nc e/user/ 1235
  • DAAP Digital Audio Access Protocol from AppleTM
  • the unique identifier here after also called a hash, is determined by the media file manipulation portion 120 of FlG.1. Its c o mp uta tio n maybe achieved a fte r c o lie c ting the information available for each media file accessible on the different storage libraries, as illustrated later on.
  • the computation of the hash may be achieved by a hash plug-in stored on the media file manipulation portion 120. Kno wn computation algorithms may be readily used to determine its value using the metadata (partly or completely) and/orthe data content of a media fie.
  • a hash algorithm or function is a function that "chops and mixes" (Le., substitutes or transposes) the data it is applied to to create a fingerprint or unique identifier, often called a hash value.
  • Hash values are used commonly in c ryp to g ra p hy.
  • a g o o d ha sh func tio n is o ne tha t yie Id s fe w - if no - ha sh c o Disio ns when used on an input domain, like media items.
  • the hash has to be unique all over the system according to the present system.
  • the hash algorithm may vary depending on the media file type. Tb make sure that two different algorithms applied on two different types of media file s re turn d iffe re nt hashes, in accordance with a further embodiment of the present system, a unique prefix or postfix is attached to the hash to specify which plug-in (Le. which algorithm) has been used.
  • the hash is the ID of a media item in the system according to the present system, hone embodiment, two media items have the same hash if and only if they are instances of a single media item. In some instances, multiple (Le. distinct) items may collide in the same hash. In such instance, one way to avoid collision is to include additional elements from the metadata into the hash computation (e.g., the title of the song, ).
  • the catalog in the system is the list of media items that are available to the system and its user.
  • Each entry of the catalog corresponds to a media item.
  • the entry may comprise the metadata of the media item, its unique identifier, and the location wherein the data content of the item can be retrieved.
  • the catalog may be organized using any representation suitable to the man skilled in the art, provided that for each entry to the catalog, the hash is associated at least to the location of the data content of the media item. In the system ace ording to an embodiment, only part of the metadata may be stored in the catalog even if the whole metadata is available on the storage library.
  • the user may choose which information from the item metadata is relevant to him, so thathe/she canselectthe p Ia ylist content based o n his/ he r o wn c rite ria .
  • the librariesthe system according to the present system has access to are generally managed by one or more servers.
  • the way media items are stored in the library and the way to access said libraries may be different from one server to the other.
  • the media file manipulation portion is furthe r a rra ng e d to browse and access the media files stored in each library.
  • at least fo ur func tio ns should be available to the system according to the present system on each of the servers: - browsing the list of media items stored in the library, -the retrieval of the metadata associated for each media item, Le. each metadata is re turned to the system,
  • each address is returned to the system, -the retrieval of the data content associated to each media item, taking into account the protocolnecessary to transfer said data content.
  • the p Ia ylist generated by the system according to the present system is a list of entry that comprises at least the unique id e ntifie r fo r each media item that has been selected.
  • the p Ia ylist may simply be a list of hashes that is stored on the medium storage 110.
  • the retrieval of the corresponding metadata in the catalog allows a visualization (through a graphic use r inte rfa c e or GUI, not shown in FlG.1) of the catalog in a convenient way to the user.
  • FIG.2 shows a p roc ess flowchart in accordance with an embodiment of the method according to the present system.
  • the list of servers is actually maintained by the server plug -ins.
  • the plug -ins are responsible for declaring all the available servers of their kind, and by the same token the content of the libraries they manage.
  • a list of available servers may be stored in the system according to the present system, this list is kept up-to-date each time a server is added or removed.
  • the number of libraries NBJJB is set to the total number of libraries the system according to the present system has access to .
  • an initiation of the catalog update is started.
  • update as including the whole catalog creation as the creation itself can be seen as an update.
  • a counter C OUNTER_SERVER, pointing to the c urre nt lib ra ry under review is set to its initial value 1.
  • two different triggering events may cause the catalog to be updated: -a se rve r no tifying a modification. This includes a new server coming up on the network, e.g. a server ma nag ing a library the user has added on the list of libraries accessible to the system,
  • a full check of the media libraries may be carried out periodically to make sure a no tific a tio n o f a modification has not been lost in the network.
  • the time interval between updates may depend e.g. upon the user requirements and/ or the type of servers.
  • Le. step 200 may be carried out in an alternative embodiment right after the initiation of triggering step 210.
  • a tag CHECKED is set to a default value for all entries in the catalog. This tag will be updated each time the entry has been updated.
  • a library/ server is further selected instep 220, among the lib ra rie s id e ntifie d instep 200.
  • the system collects the selected server type. This may be achieved through the retrieval of a server ID. The identification of the type of server allows the system API to access the media content of the library managed by said server, via the identified plug -in.
  • the selected library -orlibrary under review - is parsed to identify its content. Media item information, including its metadata and location, is retrieved. This information is stored in the catalog of the system according to the present system provided its has not been stored before or a change ofthe address has occurred since the previous update ofthe catalog.
  • a hash value is computed for said library based on its content (metadata of media items and/or data content) and stored in the system.
  • This library hash may be stored with the list of server ID.
  • the system computes again the library hash and compares it to the hash value stored for said library. Identical hashes means that the library has not been updated and its content doe snot need to be parsed.
  • COUNTER_SERVER is incremented by one unit. Provided the new value is lower tha n o r e q ua 1 to the to ta 1 numb e r of id e ntifie d lib ra rie s NB_IJB as c he c ke d in step 250, the select step 220 is repeated.
  • a final update of the catalog is achieved through removing all information related to servers and libraries that are no longer accessible by the system according to the present system. This may be implemented through the storing ofthe server ID with the metadata and address of a media item in the catalog. All entry in the c atalog that comprises the ID of a lib ra ry/ se rve r whic h has been removed may be suppressed from the catalog. The person skilled in the a rt will und e rsta nd that step 260 may be achieved right after step 200 or 210.
  • FlG.3 illustrates a detailed flowchart of the parse step 230 in FIG.2.
  • a library is parsed item per item in the steps 300 to 360.
  • the system according to the present system collect from the selected server the number of media items NB_HEM stored in the library under review.
  • a counter pointing at the current item under review is set to an initial value of 1.
  • a tag CHECKED is set to a default value for all entries in the catalog corresponding to the library under review. These entries may be identified through the server ID.
  • This step maybe carried out as an alternative embodiment to the step of setting alltagsinthe catalog to said default value as described with regards to FIG.2.1n a furtherstep 310 of the method according to the present system, a current item of the library is reviewed, with the help of the functions allowed through the selected server plug-in.
  • the type of the media file under review is retrieved in order to select the right hash algorithm to generate the hash associated to said media item.
  • the hash is computed through at least part of the metadata of the media file and/or its data content.
  • the hash may be generated by the system itself. In this instance the information required for its computation is transferred from the selected library to the system itself.
  • the hash is computed by the selected server and transferred after its computation to the system.
  • the catalog is updated. Tb do so, the system seeks through the catalog the generated hash. F the hash is not found, the catalog is updated with a new entry corresponding to the media item, Le., its metadata, its hash, and its address.
  • the metadata may include the server ID as well as the type of media item.
  • F the ha sh is fo und , the address is updated to the current address for the media item underreview.
  • the stored address may be left unchanged provided it has not changed. In both instances, the value of the tag CHECKED is changed to a different value, to signal that the entry has been updated.
  • the system checks if the media item under review is the last item of the media items stored in the library under re view. If not, the parsing is resumed at step 310 with the next media item of the library. The c o unte r p o inting at the item under review is increased by 1.
  • step 360 a last update of the catalog for the library under review is performed.
  • Some hashes stored in the catalog may not have been compared to the generated hashes during the steps 310 to 350. These are the items which were not retrieved during the parsing of the library. For said entries, the tag
  • CHECKED when provided, is still set to its initial value.
  • these entries are removed from the catalog.
  • the entries correspond e.g. to media items which have been removed from the library/ server under re view.
  • a p Ia ylist is generated from the catalog thanks to the playlist processor 125 of FIG.1.
  • the playlist comprises as defined before at least the list of hashes corresponding to the media files selected by the user or by a playlist generator.
  • FIG.4 shows a flowchart of the use of a playlist in the system according to the present system.
  • the system opens the playlist in step 410. This step is carried out by the media file manipulation portion 120 of FIG.1.
  • the playlist may be displayed by a GUI of the system by displaying on said GUI the metadata (or part of it, based on the user's preferences) in the catalog associated to each hash of the playlist.
  • a counter is set to 1.
  • the counter points to the current entry - or entry under review - of the playlist that is to be played by the playback device 130 of FlG.1.
  • the p Ia ylist entry under review comprises a hash which is called here afterthe current hash.
  • the catalog entry corresponding to the current hash is retrieved, including the location of the media file.
  • the data content of the catalog entry is retrieved on the library it is stored on thanks to the plug-in of the associated server.
  • the data content is then sent in step 460 to the playback device for rendering.
  • the playback device may comprises different rendering devices depending on the type of media item to render.
  • the rendering device may include, but not limited0 to, speakers, a GUI, ...
  • the counter is implemented by 1, pointing to the next entry in the playlist, and the step 440 is repeated with the corresponding hash as the new current hash.
  • Steps 440 to 470 may be repeated for all playlist5 entries.
  • the user may choose at any time to stop the rendering of the media items in the playlist. He/she may also choose a random option to render the playlist content in a random order.
  • the media items selected in the playlist are then rendered in a random order using a suitable random function.
  • a further step 480 maybe carried out to either select or generate a different playlist.
  • Other functions of the system may be readily available to the user.
  • FIG.5 shows a device 500 in accordance with an embodiment of the present system.
  • the device has a processor 510 operationally coupled to a memory 520, a5 display 530, a user input device 570 and one or more rendering devices 540.
  • the memory 520 which comprises the medium storage 110 from FIG.1, may be any type of device for storing programming application data, such as to support a user interface (e.g., GUD, as well as other data, such as content items, content libraries, content characteristic descriptions (e.g., metadata), etc.
  • the programming application data and other data are received by the processor 510 for configuring the processor ⁇ lO to perform operation actsin accordance with the present system.
  • the operation acts may include controlling the display 530 to display the data content attached to a playlist entry, if any, a nd/ o r c o ntro Hing the rendering device to rendercontent in accordance with a generated orsaved playlist.
  • the user input 570 may include a keyboard, mouse, trackball or other device, such as a touch sensitive display, which maybe stand alone orbe a partofa system, such as part of a personalcomputer, personal digital assistant, content rendering device (e.g., MP3 player) ordisplay device for communicating with the processor 510 via any type of link, such as a wired or wireless link.
  • the user input device 570 is operable for interacting with the processor ⁇ lO including interaction within a paradigm of a GO, selection of content, generation of playlists, selection of storage libraries, attributes and/or other elements of the present system.
  • the processor 510, memory 520, display 530, user input device 570, and/orcontentrendering device 540 may all or partly be a portionofa computer system or other device, such as a dedicated content rendering device (e.g., portable music player).
  • the methods of the present system are particularly suited to be carried out by a computer software program, such program containing modules corresponding to one or more of the individual steps or acts described and/or envisioned by the present system.
  • a computer software program such program containing modules corresponding to one or more of the individual steps or acts described and/or envisioned by the present system.
  • Such program, media items, medium storage, etc. may of course be embodied in a computer-readable medium, such as an integrated chip, a peripheral device or memory, such as the memory 520 and/or other memory coupled to the processor ⁇ lO.
  • the memory 520 may be any recordable medium (e.g., RAM, ROM, removable memory, CD-ROM, hard drives, DVD, floppy disks or memory cards) or maybe a transmission medium (e.g., a network comprising fiber-optics, the worldwide web, cables, a wireless channel using time-division multiple access, code- division multiple access, or other radio-frequency or wireless communication channel). Any medium known or developed that may store and/or transmit information suitable foruse with a c o mp ute r syste m maybe used as the memory 520.
  • a transmission medium e.g., a network comprising fiber-optics, the worldwide web, cables, a wireless channel using time-division multiple access, code- division multiple access, or other radio-frequency or wireless communication channel.
  • Any medium known or developed that may store and/or transmit information suitable foruse with a c o mp ute r syste m maybe used as the memory 520.
  • the memory 520, and/or any other memories may be long-term, short-term, or a combination of long-term and short- term memories. These memories configure processor 510 to implement the GUk, methods, operational acts, rendering devices and functions disclosed herein.
  • the memories may be distributed or local and the processor 510, where additional processors may be provided, may also be distributed or may be singular, e.g. the servers the system has access to that are used to manage the libraries storing the media items.
  • the memories may be implemented as electrical, magnetic or optical memory, or any combination of these or othertypes of storage devices.
  • memory should be construed broadly enough to encompass any information able to be read from orwritten to an address in the addressable space accessible by a processor. With this definition, information on a network is still within memory 520, for instance, because the processor 510 may retrieve the information from the ne two rkfor operation in accordance with the present system.
  • the processor 510 is capable of providing control signals and/or performing operations in response to input signals from the user input device 570 and executing instructions stored in the memory 520.
  • the processor 510 may be an application- specific and/or general-use integrated circui s).
  • the processor ⁇ lO may be a dedicated processor for performing in accordance with the present system and/or may be a general-purpose processor wherein only one of many functions operates forperforming in accordance with the present system.
  • the processor ⁇ lO may operate utilizing a program portion, multiple program segments, and/or may be a hardware device utilizing a dedicated or multi-purpose integrated circuit. Further, in a distributed system, portions of an operation may be performed on one device with data generated therefrom being transferred to one or more further devices.
  • a playlist may be generated onone device (e.g. comprising playlist processor 125) with results from the playlist being transferred to a further device, such as the media fOe manipulation portion 120.
  • a first processor, orcatalog processor isprovided with the media file manipulation portion while a second processor, orplaylist processor, is provided to generate the playlist. Both processors are operatively coupled to each other, to allow the retrieval of the data content of a media file through its corresponding hash in the catalog.
  • a playlist may be generated on a device such as a computer with the playlist thereafter being exported to a rendering device such as an audio rendering device (e.g., MP3 player, AAC player, etc.), provided the rendering device has access to the catalog to retrieve thanks to the hash the right data content for each playlist entry.
  • processors and memories may be distributed between atleast these two devices. The man skilled in the art willalso understand that only one processor may be necessary to perform the acts performed by the media file manipulation device and the playlist processor, Le. this one processorisboth the catalog and the playlist processor.
  • any one of the above embodiments or processes may be combined with one or more other embodiments and/or processes orbe separated and/orperformed amongst separate devices or device portions in accordance with the present system.

Abstract

A method to manage media files, each media file being characterized by a metadata and a data content to be rendered, said method comprising the steps of generating a catalog of media file entries, each media file entry corresponding to a media file, said step of generating a catalog comprising for each media file entry the steps of collecting the media file metadata of said media file, collecting an up -to -date address for retrieval of said data content of said media file, and computing a unique identifier at least on part of said media file metadata. The method further comprises the step of generating a playlist from media file entries selected in said catalog, said playlist comprising at least for each selected media file entry its unique identifier. Finally, for at least part of each selected media file entry of said playlist, its unique identifier is searched in the catalog, and the corresponding data content is retrieved from the up -to - date address associated to said unique identifier, and is rendered.

Description

MEDIA HIE SEKVER
FIELD OFTHEFBESENTSYSTEM: The present devic e relates in general to the management of media files stored in one or more data bases, and more specifically to the retrieval of such media file s se Ie c te d fora playlist when these files are relocated or moved.
BACKGROUND OFTHE FKESENTSYSIEM: Nowadays, it is common for an user to access different data bases or libraries to retrieve media files, also called here after media items. The data bases may be stored on different servers or c omputers, here after c ailed sourc es. A media item, Le. an audio, video, text, or any other media type, is generally defined by both its meta data and its c ontent. The meta data generally refers to the information on the media fie, Le. its title, artist, album name, director (fora movie), duration, bit perminute, ... The content is the data that is retrieved to be viewed and/ or listened to.
Through a home entertainment system, a computerora media playerfor example, one may have access to different sources and libraries over which the media items are distributed. The media file contents are generally played or rendered through a playback device (or media rendering device). By rendering, one may understand providing content, such as digital media, such that it may be perceived by at least one user sense, such as a sense of sight and/ or a sense of hearing. The media rendering device may be a personal computer, an MP3/MP4 player, a DVD player, orany other suitable device that can play media files. The different source Io cations may comprise the playback device storage.
Tb play a list of media files, one may regroup a selection of such files in a playlist. A playlist is a common tool adopted by the software programs from media rendering devices intended to organize and control media files. Such playlists may be defined, stored, and selected to either run media files in sequence or, if a random playlist function is selected, in a random order. A playlist may also be described as a sequence of selected objects to be rendered. The function of a playlist is generally to identify the objects it refers to so that said objects can be communicated to the rendering device according to the ir o rd e r in the playlist.
Playlist are generally organized in a table associating the media file metadata to an address from which the media file content can be retrieved for an immediate or later play. For different reasons one may need to move files from one source to another. Furthermore, the same file maybe located on two different storage locations. With known playlist architectures, whenever a file is moved to or duplicated on a different source, the playlist may be broken as the address in the playlist is not updated. This may result in a corrupted playlist, that will cause the media rendering device to skip the file or simply stop playing the files. In other words if the playlist is generated with the initial content of a media file library, any further reorganization of the library content (e.g. media files moved to different addresses) may result in a broken playlist that cannot be rendered on a playback device.
Today there is a need for a method to generate a playlist that will not cause any disturbance when its content is rendered, no matter when the playlist was created. There is a further need fora system that allows to generate such playlist.
SUV-MAKT OFTHE FBESBNTSYSTEM: It is an object of the present system to address a device and a method to overcome disadvantages and/ormake improvements in the prior art.
The present system includes a method and system for generating a reliable playlist to be rendered on a playback device. Accordingly, the present system relates to a method to manage media files, each media file being characterized by a metadata and a data content to be rendered, said method c omprising the steps of:
- generating a catalog of media file entries, each media file entry c orresponding to a media file, said step of generating a catalog comprising foreach media file e ntry the ste p s o f:
- collecting the media file metadata of said media file,
- collecting an up-to-date address for retrieval of said data content of said media fie, -computing a unique identifier at least on part of said media file metadata,
-generating a playlist from media file entries selected in said catalog, said p Ia ylist comprising at least foreach selected media file entry its unique identifier, and, for at least part of each selected media file entry of said playlist: -searching its unique id e ntifie r in the catalog,
-retrieving the corresponding data content from the up-to-date address associated to said unique identifier,
-rendering said data content.
With the association in the playlist of a selected media file entry with its unique identifier, the problem of updating the address of a media file is transferred to the step of generating the catalog. A regular update of the catalog each time an address is changed (new file, new library storing media files, removal of a file, removal of a library) or a periodic update ensures that the unique identifier points to the right address wherein the media file content is sto re d .
In an additional embodiment, the step of computing the unique identifier is furthe r c a rrie d out taking into account the data content of the media fie. The identifier, or hash as explained later on, may be generating using different data identifying a media fie, provided the hash is unique to said media fie. ha further embodiment of the method according to the present system, the media files are stored in a plurality of storage libraries, and the step of generating a catalog furthe r c o mp rise s the step of retrieving the list o f sto ra g e libraries the media files are stored in.
In accordance with a further embodiment of the present system, the step of generating the catalog further comprising the steps of associating a library identifier for each storage lib ra ry, a nd , a sso c ia ting for each media file entry the library identifier where in the contentdata forthe media file canbe retrieved. In accordance with an additional embodiment of the present system, the step of generating the catalog further comprises the step of collecting the type of media file for each media file entry.
In accordance with an additional embodiment of the present system, the media files are stored in a plurality of storage libraries, a triggering event forthe step ofgenerating the catalog being atleastone of:
-the change of a media file address,
-the addition of a media file to a storage library,
-the removalofa media file to a storage library,
-the addition of a storage library, -the removalofa storage library,
-a periodic update of the catalog.
In accordance with a further embodiment of the present system, the step ofgenerating the catalog is carried out forthe media files and storage libraries that caused the triggering event. The present system also relates to system to manage media files, each media file being characterized by a metadata and a data content to be rendered, said system comprising:
- a medium storage to store a catalog of media file entries, each media file entry corresponding to a media file and comprising: -the media file metadata of said media file,
-a unique identifier for said media file based at least on part of said media file metadata,
- an up-to-date address for retrieval of said data content of said media file,
- a playlist processor operationally coupled to the medium storage and arranged to generate a playlist of media files selected in the catalog, said playlist comprising at least foreach selected media file its unique identifier, wherein the data content of each selected media file of the playlist is retrieved by searching in the catalog the up-to-date address corresponding to its unique id e ntifie r.
In an accordance with an additional embodiment of the present system, the media files are stored in a plurality of storage libraries, and the system further comprises a catalog processor opera tively coupled to the medium storage, said processorbeing arranged to:
-retrieve the media file s o n sa id p lura lity o f sto ra g e libraries, -compute the unique identifier, -store the catalog ofmedia file entries.
In accordance with a further embodiment of the present system, the catalog processor is further arranged to retrieve the data content of each selected media file of the playlist by searching in the catalog the up-to-date address corresponding to the unique identifier.
Furthermore, the unique identifier is computed furthe r ta king into account the data content of the media file. In accordance with an additional embodiment of the present system, each library is associated with a library identifier, and wherein the catalog processorisfurtherarranged to:
-associate foreach media file entry the library identifier wherein the content data forthe media file can be retrieved. Furthermore, the media files are stored in a plurality of storage libraries, the system comprising a catalog processor arranged to generate the catalog upon the occurrence of a triggering event, said triggering event be ing at least one of:
-the change of a media file address, -the addition of a media file to a storage library,
-the removalofa media file to a storage library,
-the addition of a storage library,
-the removalofa storage library
-a periodic update of the catalog. In accordance with an additional embodiment of the present system, the catalog processoris further arranged to generate the catalog forthe media files and storage libraries that caused the triggering event.
Furthermore, the present system relates to an application embodied on a computer readable medium arranged to manage media files, the application co mp rising :
-a portion to generate a catalog of media file entries, each media file entry corresponding to a media fie, said portion of generating a catalog comprising fo r e a c h me dia file e ntry a p o rtio n to :
- collect the media file metadata of said media fie, - collect an up-to-date address for retrieval of said data content of said media fie,
- c ompute a unique identifier at least on part of said media fie metadata, -a portion to generate a p Ia ylist from media fie e ntrie s se Ie c te d in said catalog, said playlist comprising at least for each selected media fie entry its unique id e ntifie r, and, for at least part of each selected media fie entry of said playlist a portion to:
- search its unique id e ntifie r in the catalog, -retrieve the corresponding data content from the up-to-date address associated to said unique identifier, -render said data content.
BKIEΓDESCKIPΠON OF THE DRAWINGS:
The present device is explained in further detail, and by way of example, with reference to the accompanying drawings wherein:
FlG.1 illustrates one embodiment of the system to generate an a playlist according to the p re se nt syste m ; FlG.2 illustra te s o ne embodiment of a flowchart related to the collecting of the media items on different servers, in accordance with one embodiment of the method according to the p re se nt syste m ;
FlG.3 illustrates a detailed flowchart of the parsing step of FIG.2;
FIG.4 illustrates a flowchart related to a playlist generation in the system according to the present system.; and,
FIG.5 illustrates a device in accordance with an embodiment of the present system.
DEBULBD DESCHPDON OFTHE FΪΦSENTSYSIEM: The following are descriptions of illustrative embodiments that when taken in conjunction with the following drawings will demonstrate the above noted featuresand advantages, as we H a s furthe r o ne s. In the following description, for purposes of explanation rather than limitation, illustrative details are set forth such as architecture, interfaces, techniques, element attributes, etc . However, it willbe apparent to those of ordinary skill in the art that other embodiments that depart from these details would stillbe understood to be within the scope of the appended claims. Mo re o ve r, fo r the purpose of clarity, detailed descriptions of well known devices, circuits, modeling tools, analysis techniques and methods are omitted so as not to obscure the description of the present system. It should be expressly understood that the drawings are included for illustrative purposes and do not represent the scope of the present system.
In accordance with an embodiment of the present system, a system 100 as shown in FlG.1 is provided for generating a playlist. The system 100 includes a medium storage 110, a media file manipulation portion 120, a playlist generation portion 125 and a playback device 130.
In the system according to the present system, each media file is characterized by a metadata and a data content. The data content may include audio content, video content, audio/visual content, image content, textual content, and/or other content that may be rendered to a user. The metadata may include artist's name, author's name, album title, rendering length of a media file content, its year of production, genre, b e a ts-p e r-minute , tone, tempo, ranking according to a user's taste, and/or any other characteristics that may be utilized to suitably describe characteristics of the media file. In the system according to the present system, the data content of a media file is associated as explained later on with an address or a path indicating where the content can be retrieved. This address may be provided e .g . in the fo rm o f a URL(unifo rm re so urc e Io c ato r) a ddre ss.
The medium storage 110 is an indexing storage that stores some available information (including the metadata) for each media file collected on a plurality o f c o nte nt lib ra rie s 1 to N - with N a n inte gergreater the nθ-asexpla ine d Ia te r on. The available information is stored in the form of a catalog of media file entries. In other words, the catalog regroups in a list information on the media files available on the different libraries 1 to N accessible to the system according to the present system.
The file manipulation portion 120 is arranged to generate the catalog of media file entries stored on the medium storage 110. The media file manipulation portion 120 is therefore operatively coupled to the medium storage 110. Tb that effect, the media file manipulation portion 120 may comprise a processor called here aftera catalog processor.
The media file manipulation portion 120 is thus arranged to access the different storage libraries 1 to N to enable the collection and storage on the medium storage 110 of the available information for each media item. Each entry in the catalog correspond to a media item. Tb collect the information, the media file manipulation portion 120 is connected to the d iffe re nt c o nte nt lib ra rie s by any suitable transfer protocol as explained later on. The content libraries may be located on remote sources associated to servers. One or more content libraries may also be located on one or more local storages linked to, orpartof the indexing storage 110.
In the system according to the present system, the media file manipulation portion 120 further stores an up-to-date address for the data content associated to each media file entry. The media file manipulation portion 120 is further arranged to allow the retrieval of said data content for each entry in the catalog. The retrieval is based on the media file up-to-date address stored with e a c h e ntry in the c atalo g .
In the system according to the present system, the media file manipulation portion 120 is also arranged to generate a unique identifierforeach media item, based on the collected media item information and/or its corresponding data content as explained lateron.
The system according to the present system furthe r c o mp rise s a playlist processor 125 arranged to generate a playlist of media files, eitherusing a user input through a use r inp ut inte rfa c e - no shown in FlG.1 - or any suitable playlist generation method. The available media items for creation of the playlist are the media files corresponding to the entries in the catalog stored in the medium storage 110. The playlist processor 125 is therefore operatively coupled to the media file manipulation portion 120, and consequently to the medium storage 110. The playlist processor 125 is arranged, when generating a playlist of media files, to include in said playlist at least the unique identifier of each selected media file.
Afterthe playlist is generated, it may be saved (on medium storage 110 or a separate storage) for later use. The selected media items may also be rendered by the media rendering device 130, sequentially or randomly, after theirdata content is retrieved by the media file manipulation portion 120 through their unique identifier in the playlist. Indeed, the unique identifier allows the media file manipulation portion 120 to point in the catalog to an up-to-date address for the data content. Thus the manipulation portion 120 may retrieve in one of the storage libraries the data content and forward it to the rendering device 130.
In the system according to the present system, the playlists are associated to the catalog. The catalog indexes (through the retrieval of the available data on the different libraries) all the media files available to the system. For each media item, a unique id e ntifie r is g e ne ra te d that allows to point to said media file in the system according to the present system. The usermay be the ownerof a 11 the me d ia file s. The use r c a n inc re a se the numb e r o f file s he / she ha s a c c e ss to by adding more files to one of more of the storage libraries, o r sub sc rib ing to online storage libraries. The usermay also acquire additional media files through purchasing files on the internet through e.g. his/her laptop, or download available video files through pod casting.
The medium storage 110 along the media file manipulation portion 120 form a central server in the system according to the present system, also called the indexing server. This indexing server will collect data available on the different storage libraries as explained here after.
The person skilled in the art will understand that the indexing storage 110, the media file manipulation portion 120, the playlist processor 125 and the media rendering device 130 may all be part of the same device, e.g. a server or a computer. Each of these different elements may also be part of separate devices, or some of them may be regrouped in the same device. For example, the medium storage 110 and the media file manipulation portion 120 may be comprised within a first device like a server or a personal computer while the media rendering device 130 and the playlist processor 125 may be part of a second device, like a portable media player, e.g. an MP3 player (docketed on a suitable port of the first device). The second device is operatively coupled to the first so that the second device, after generating the playlist based on the catalog entries, renders the selected media files as their unique identifier points to an up-to-date address in the catalog. As seen in FlG. 1, the user can in the system according to the present system access through the catalog to a plurality of storage libraries, as each entry in the catalog comprises an up-to-date address for the media item. The address, also called here after the location, of a media file on one of the storage libraries is what will allow the system to get to the data content of an identified media fie. Tb allow such a retrieval, the address allows access to resources on different ma chines/ servers, using different protocols. In accordance with a further embodiment of the present system, the address to retrieve the data content includes the transferprotocolthat is used to access said data content. Forexample, the location may be written as follows: < protocol>://< serve r>/< resource local id > wherein:
Figure imgf000012_0001
Table 1: location description in the system according to the present system Tb access a file singer.mp3 on a local storage nfs, and stored in the directory John/ storage/music/pop, the location may be the following: nfs://localhost/home/john/storage/music/pop/singer.mp3 To access a fie movie.avi over the internet using rtps (data distribution se rvic e ) to a c c e ss the www.cc ccom web site , the Io c a tio n ma y b e the fo Uo wing : rtps:// www. c cc.c om/mo vie /movie.avi
Tb access a song with an ID 1235 in a user collection on a server quintessence using DAAP (Digital Audio Access Protocol from Apple™), the address may be: lune s:// quinte sse nc e/user/ 1235
Such an approach allows to deal with heterogeneous servers and storage libraries. No matterwhat pro tocolis used to transferthe data content of a media file, the right plug -in (Le. computer pro gram) of the server being parsed iscalled by the system upon recognition of the transfer protocol in the address (stored in the catalog). Thus, the API (application programming interface) of the system according to the present system may browse a storage library through the suitable server plug -in.
The unique identifier, here after also called a hash, is determined by the media file manipulation portion 120 of FlG.1. Its c o mp uta tio n maybe achieved a fte r c o lie c ting the information available for each media file accessible on the different storage libraries, as illustrated later on. The computation of the hash may be achieved by a hash plug-in stored on the media file manipulation portion 120. Kno wn computation algorithms may be readily used to determine its value using the metadata (partly or completely) and/orthe data content of a media fie. A hash algorithm or function is a function that "chops and mixes" (Le., substitutes or transposes) the data it is applied to to create a fingerprint or unique identifier, often called a hash value. Hash values are used commonly in c ryp to g ra p hy. A g o o d ha sh func tio n is o ne tha t yie Id s fe w - if no - ha sh c o Disio ns when used on an input domain, like media items.
In choosing the hashing algorithm, one may bear in mind that the hash has to be unique all over the system according to the present system. The hash algorithm may vary depending on the media file type. Tb make sure that two different algorithms applied on two different types of media file s re turn d iffe re nt hashes, in accordance with a further embodiment of the present system, a unique prefix or postfix is attached to the hash to specify which plug-in (Le. which algorithm) has been used. The hash is the ID of a media item in the system according to the present system, hone embodiment, two media items have the same hash if and only if they are instances of a single media item. In some instances, multiple (Le. distinct) items may collide in the same hash. In such instance, one way to avoid collision is to include additional elements from the metadata into the hash computation (e.g., the title of the song, ...).
The catalog in the system according to the present system is the list of media items that are available to the system and its user. Each entry of the catalog corresponds to a media item. The entry may comprise the metadata of the media item, its unique identifier, and the location wherein the data content of the item can be retrieved. The catalog may be organized using any representation suitable to the man skilled in the art, provided that for each entry to the catalog, the hash is associated at least to the location of the data content of the media item. In the system ace ording to an embodiment, only part of the metadata may be stored in the catalog even if the whole metadata is available on the storage library. In accordance with a further embodiment of the present system, the user may choose which information from the item metadata is relevant to him, so thathe/she canselectthe p Ia ylist content based o n his/ he r o wn c rite ria .
In the hereafter description, the catalog will be illustrated using an xml description. Other representations readily available to the man skilled in the art may be used. The catalog in xml language may lookKke: <catalog>
<media>
<hash> afjklesdoini2k45ds6t5h3c5f6yt7e9qc5 </hash> <title > Pa ss the Pe a s </ title >
<a rtist> Ma c e o Pa ike r </ a rtist> <album> life on planet groove </album> <g e nre > Blue s </ g e nre >
<lo c atio n> http://70.88.212.154:6500/home/peas.mp3 </lo c atio n> </media>
<media>
<hash> a5f5iβg6h2h48y3b54n8y6b54bn6t7e9qc5 </hash> <title> These boots are made for walking </ title > <a rtist> Na nc y Sna tra </ a rtist> <album> Rill metal jacket </album>
<g e nre > Blue s </ g e nre >
<lo c atio n> http :// 70.88.212.154:6500/ ho me/ b o o ts.mp 3 </lo c atio n> </media>
</catalog>
The librariesthe system according to the present system has access to are generally managed by one or more servers. The way media items are stored in the library and the way to access said libraries may be different from one server to the other. In the system according to the present system, the media file manipulation portion is furthe r a rra ng e d to browse and access the media files stored in each library. Forthat matter, at least fo ur func tio ns should be available to the system according to the present system on each of the servers: - browsing the list of media items stored in the library, -the retrieval of the metadata associated for each media item, Le. each metadata is re turned to the system,
- the retrieval of the media item address on the library, Le. each address is returned to the system, -the retrieval of the data content associated to each media item, taking into account the protocolnecessary to transfer said data content.
These functions may be achieved through a plug-in software available on each server. Such a plug -in allows the system API to exchange information with each server to update the catalog as described lateron. The p Ia ylist generated by the system according to the present system is a list of entry that comprises at least the unique id e ntifie r fo r each media item that has been selected. Thus, the p Ia ylist may simply be a list of hashes that is stored on the medium storage 110. The retrieval of the corresponding metadata in the catalog allows a visualization (through a graphic use r inte rfa c e or GUI, not shown in FlG.1) of the catalog in a convenient way to the user. The same GUImaybe used to visualize the playlist as it is created or retrieved from the medium storage 110. Different syntaxes are readily available to the man skilled in the art. For illustration purposes, an example of a playlist using an xml description would be the following: <playlist>
<item>afJklesdoiru2k45ds6t5h3c5f6yt7e9qc5</item> <item>a5f5r8g6h2h48y3b54n8y6b54bn6t7e9qc5</item> <item>afJklesdoiru2k45ds6t5h3c5f6yt7e9qc5</item> <item>af7h7t8vlb5hf68cdr6c6b5h9h62s65er4s</item>
<playlist>
The catalog updating as well as the playlist rendering will be described here after.
FIG.2 shows a p roc ess flowchart in accordance with an embodiment of the method according to the present system. In an initial step 200, the different libraries the system has access to are identified. The list of servers is actually maintained by the server plug -ins. The plug -ins are responsible for declaring all the available servers of their kind, and by the same token the content of the libraries they manage. A list of available servers may be stored in the system according to the present system, this list is kept up-to-date each time a server is added or removed. The number of libraries NBJJB is set to the total number of libraries the system according to the present system has access to .
In a subsequent step 210 of the method according to the present system, an initiation of the catalog update is started. Here after, one may understand update as including the whole catalog creation as the creation itself can be seen as an update. A counter C OUNTER_SERVER, pointing to the c urre nt lib ra ry under review is set to its initial value 1. In the system according to the present system, two different triggering events may cause the catalog to be updated: -a se rve r no tifying a modification. This includes a new server coming up on the network, e.g. a server ma nag ing a library the user has added on the list of libraries accessible to the system,
-a timer. A full check of the media libraries may be carried out periodically to make sure a no tific a tio n o f a modification has not been lost in the network. The time interval between updates may depend e.g. upon the user requirements and/ or the type of servers.
The identification of all the servers the system has access to, Le. step 200 may be carried out in an alternative embodiment right after the initiation of triggering step 210. In an additional embodiment of the method according to the present system, a tag CHECKED is set to a default value for all entries in the catalog. This tag will be updated each time the entry has been updated.
A library/ server is further selected instep 220, among the lib ra rie s id e ntifie d instep 200. In accordance with a further embodiment of the present system, the system collects the selected server type. This may be achieved through the retrieval of a server ID. The identification of the type of server allows the system API to access the media content of the library managed by said server, via the identified plug -in. In a subsequent step 230, the selected library -orlibrary under review - is parsed to identify its content. Media item information, including its metadata and location, is retrieved. This information is stored in the catalog of the system according to the present system provided its has not been stored before or a change ofthe address has occurred since the previous update ofthe catalog. In an alternative embodiment ofthe step 230 ofthe method ace ording to the present system, each time a new library is added to the catalog, a hash value is computed for said library based on its content (metadata of media items and/or data content) and stored in the system. This library hash may be stored with the list of server ID. Before parsing the entire content of the library, the system computes again the library hash and compares it to the hash value stored for said library. Identical hashes means that the library has not been updated and its content doe snot need to be parsed.
In a further step 240 of the method according to the present system, COUNTER_SERVER is incremented by one unit. Provided the new value is lower tha n o r e q ua 1 to the to ta 1 numb e r of id e ntifie d lib ra rie s NB_IJB as c he c ke d in step 250, the select step 220 is repeated.
In a subsequent step 260, a final update of the catalog is achieved through removing all information related to servers and libraries that are no longer accessible by the system according to the present system. This may be implemented through the storing ofthe server ID with the metadata and address of a media item in the catalog. All entry in the c atalog that comprises the ID of a lib ra ry/ se rve r whic h has been removed may be suppressed from the catalog. The person skilled in the a rt will und e rsta nd that step 260 may be achieved right after step 200 or 210. FlG.3 illustrates a detailed flowchart of the parse step 230 in FIG.2. A library is parsed item per item in the steps 300 to 360. In an initial step 300, the system according to the present system collect from the selected server the number of media items NB_HEM stored in the library under review. A counter pointing at the current item under review is set to an initial value of 1. In an alternative embodiment of the method according to the present system, a tag CHECKED is set to a default value for all entries in the catalog corresponding to the library under review. These entries may be identified through the server ID. This step maybe carried out as an alternative embodiment to the step of setting alltagsinthe catalog to said default value as described with regards to FIG.2.1n a furtherstep 310 of the method according to the present system, a current item of the library is reviewed, with the help of the functions allowed through the selected server plug-in. In an additional step 320, the type of the media file under review is retrieved in order to select the right hash algorithm to generate the hash associated to said media item.
In a subsequent step 330, the hash is computed through at least part of the metadata of the media file and/or its data content. The hash may be generated by the system itself. In this instance the information required for its computation is transferred from the selected library to the system itself. In another embo diment of the system according to the present system, the hash is computed by the selected server and transferred after its computation to the system.
In a furtherstep 340 of the method according to the present system, the catalog is updated. Tb do so, the system seeks through the catalog the generated hash. F the hash is not found, the catalog is updated with a new entry corresponding to the media item, Le., its metadata, its hash, and its address. The metadata may include the server ID as well as the type of media item. F the ha sh is fo und , the address is updated to the current address for the media item underreview. In an alternative embodiment, the stored address may be left unchanged provided it has not changed. In both instances, the value of the tag CHECKED is changed to a different value, to signal that the entry has been updated.
In a subsequent step 350 of the method according to the present system, the system checks if the media item under review is the last item of the media items stored in the library under re view. If not, the parsing is resumed at step 310 with the next media item of the library. The c o unte r p o inting at the item under review is increased by 1.
When the last media item has been parsed, the method moves on to step 360 wherein a last update of the catalog for the library under review is performed. Some hashes stored in the catalog may not have been compared to the generated hashes during the steps 310 to 350. These are the items which were not retrieved during the parsing of the library. For said entries, the tag
CHECKED, when provided, is still set to its initial value. In step 360 these entriesare removed from the catalog. The entries correspond e.g. to media items which have been removed from the library/ server under re view.
In the system according to the present system, a p Ia ylist is generated from the catalog thanks to the playlist processor 125 of FIG.1. The playlist comprises as defined before at least the list of hashes corresponding to the media files selected by the user or by a playlist generator. FIG.4 shows a flowchart of the use of a playlist in the system according to the present system.
After the playlist is generated by playlist processor or a saved playlist is retrieved in step 400, the system opens the playlist in step 410. This step is carried out by the media file manipulation portion 120 of FIG.1. In an optional step 420, the playlist may be displayed by a GUI of the system by displaying on said GUI the metadata (or part of it, based on the user's preferences) in the catalog associated to each hash of the playlist.
In a furthe r initia tio n step 430, a counter is set to 1. The counterpoints to the current entry - or entry under review - of the playlist that is to be played by the playback device 130 of FlG.1. The p Ia ylist entry under review comprises a hash which is called here afterthe current hash.
In an additional step 440, the catalog entry corresponding to the current hash is retrieved, including the location of the media file. In a subsequent step 5 450, the data content of the catalog entry is retrieved on the library it is stored on thanks to the plug-in of the associated server. The data content is then sent in step 460 to the playback device for rendering. One may notice that the playback device may comprises different rendering devices depending on the type of media item to render. The rendering device may include, but not limited0 to, speakers, a GUI, ...
In a furthe r ste p 470, the syste m ve rifie s if the c urre nt p Ia ylist e ntry is the Ia st one of the playlist. In the negative, the counter is implemented by 1, pointing to the next entry in the playlist, and the step 440 is repeated with the corresponding hash as the new current hash. Steps 440 to 470 may be repeated for all playlist5 entries. The user may choose at any time to stop the rendering of the media items in the playlist. He/she may also choose a random option to render the playlist content in a random order. The media items selected in the playlist are then rendered in a random order using a suitable random function.
When the content of the playlist has been rendered, or when the user0 decides to stop the rendering, a further step 480 maybe carried out to either select or generate a different playlist. Other functions of the system may be readily available to the user.
FIG.5 shows a device 500 in accordance with an embodiment of the present system. The device has a processor 510 operationally coupled to a memory 520, a5 display 530, a user input device 570 and one or more rendering devices 540. The memory 520 which comprises the medium storage 110 from FIG.1, may be any type of device for storing programming application data, such as to support a user interface (e.g., GUD, as well as other data, such as content items, content libraries, content characteristic descriptions (e.g., metadata), etc. The programming application data and other data are received by the processor 510 for configuring the processorδlO to perform operation actsin accordance with the present system. The operation acts may include controlling the display 530 to display the data content attached to a playlist entry, if any, a nd/ o r c o ntro Hing the rendering device to rendercontent in accordance with a generated orsaved playlist. The user input 570 may include a keyboard, mouse, trackball or other device, such as a touch sensitive display, which maybe stand alone orbe a partofa system, such as part of a personalcomputer, personal digital assistant, content rendering device (e.g., MP3 player) ordisplay device for communicating with the processor 510 via any type of link, such as a wired or wireless link. The user input device 570 is operable for interacting with the processorδlO including interaction within a paradigm of a GO, selection of content, generation of playlists, selection of storage libraries, attributes and/or other elements of the present system. Clearly the processor 510, memory 520, display 530, user input device 570, and/orcontentrendering device 540 may all or partly be a portionofa computer system or other device, such asa dedicated content rendering device (e.g., portable music player).
The methods of the present system are particularly suited to be carried out by a computer software program, such program containing modules corresponding to one or more of the individual steps or acts described and/or envisioned by the present system. Such program, media items, medium storage, etc. may of course be embodied in a computer-readable medium, such as an integrated chip, a peripheral device or memory, such as the memory 520 and/or other memory coupled to the processorδlO.
The memory 520 may be any recordable medium (e.g., RAM, ROM, removable memory, CD-ROM, hard drives, DVD, floppy disks or memory cards) or maybe a transmission medium (e.g., a network comprising fiber-optics, the worldwide web, cables, a wireless channel using time-division multiple access, code- division multiple access, or other radio-frequency or wireless communication channel). Any medium known or developed that may store and/or transmit information suitable foruse with a c o mp ute r syste m maybe used as the memory 520.
Additional memories may also be used. The memory 520, and/or any other memories may be long-term, short-term, or a combination of long-term and short- term memories. These memories configure processor 510 to implement the GUk, methods, operational acts, rendering devices and functions disclosed herein. The memories may be distributed or local and the processor 510, where additional processors may be provided, may also be distributed or may be singular, e.g. the servers the system has access to that are used to manage the libraries storing the media items. The memories may be implemented as electrical, magnetic or optical memory, or any combination of these or othertypes of storage devices. Moreover, the term "memory" should be construed broadly enough to encompass any information able to be read from orwritten to an address in the addressable space accessible by a processor. With this definition, information on a network is still within memory 520, for instance, because the processor 510 may retrieve the information from the ne two rkfor operation in accordance with the present system.
The processor 510 is capable of providing control signals and/or performing operations in response to input signals from the user input device 570 and executing instructions stored in the memory 520. The processor 510 may be an application- specific and/or general-use integrated circui s). Further, the processorδlO may be a dedicated processor for performing in accordance with the present system and/or may be a general-purpose processor wherein only one of many functions operates forperforming in accordance with the present system. The processorδlO may operate utilizing a program portion, multiple program segments, and/or may be a hardware device utilizing a dedicated or multi-purpose integrated circuit. Further, in a distributed system, portions of an operation may be performed on one device with data generated therefrom being transferred to one or more further devices. For example, a playlist may be generated onone device (e.g. comprising playlist processor 125) with results from the playlist being transferred to a further device, such as the media fOe manipulation portion 120. In this instance, a first processor, orcatalog processor, isprovided with the media file manipulation portion while a second processor, orplaylist processor, is provided to generate the playlist. Both processors are operatively coupled to each other, to allow the retrieval of the data content of a media file through its corresponding hash in the catalog. In this embodiment, a playlist may be generated on a device such as a computer with the playlist thereafter being exported to a rendering device such as an audio rendering device (e.g., MP3 player, AAC player, etc.), provided the rendering device has access to the catalog to retrieve thanks to the hash the right data content for each playlist entry. In this embodiment, processors and memories may be distributed between atleast these two devices. The man skilled in the art willalso understand that only one processor may be necessary to perform the acts performed by the media file manipulation device and the playlist processor, Le. this one processorisboth the catalog and the playlist processor. Of course, itisto be appreciated that any one of the above embodiments or processes may be combined with one or more other embodiments and/or processes orbe separated and/orperformed amongst separate devices or device portions in accordance with the present system.
Hnally, the above -discussion is intended to be merely illustrative of the present system and should not be construed as limiting the appended claims to any particular embodiment or group of embodiments. Thus, while the present system has been described with reference to exemplary embodiments, it should also be appreciated that numerous modifications and alternative embodiments may be devised by those having ordinary skill in the art without departing from the broader and intended spirit and scope of the present system as set forth in the claims that follow. In addition, the section headings included herein are intended to facilitate a review but a re not intended to limit the scope of the present system. Accordingly, the specification and drawings are to be regarded in an illustrative mannerand are not intended to limit the scope of the appended claims. In interpreting the appended claims, it should be understood that: a) the word "comprising" does not exclude the presence of other elements o racts than those listed in a given claim; b) the word "a" or "an" preceding an element does not exclude the presence of a plurality of such elements; c) anyreference signsinthe claimsdo no t limit the ir sc o p e ; d) several "means" may be represented by the same item orhardware or software implemented structure orfunction; e) any of the disclosed elements may be comprised of hardware portions (e.g., including discrete and integrated electronic circuitry), software portions (e.g., computer programming), and any combination thereof; f) hardware portions may be comprised of one or both of analog and digital portions; g) any of the disclosed devices or portions thereof may be combined togetherorseparated into furtherportions unless specific ally stated otherwise; h) no specific sequence of acts orsteps is intended to be required unless specifically indicated; and i) the term "plurality of an element includes two ormore of the claimed element, and does not imply any particular range of numberof elements; that is, a plurality of elements may be as few as two elements, and may include an immeasurable numberof elements.

Claims

CIAIV-SWhat is claimed is:
1. A method to manage media files, each media file being characterized by metadata and a data content to be rendered, said method comprising the ste p s o f :
- generating a catalog of media file entries, each media file entry c orresponding to a media file, said step of generating a catalog comprising foreach media file e ntry the ste p s o f: -collecting the media file metadata of said media file,
- collecting an up-to-date address for retrieval of said data content of said media fie,
-computing a unique identifier at least on part of said media file metadata, -generating a playlist from media file entries selected in said catalog, said p Ia ylist comprising at least foreach selected media file entry its unique identifier, and, forat least part of one of the selected media file entries of said playlist:
-searching its unique id e ntifie r in the catalog,
-retrieving the corresponding data content from the up-to-date address associated to said unique identifier,
-rendering said data content.
2. The method of claim 1, wherein the step of computing the unique identifier is further carried out taking into account the data contentofthe media file.
3. The method of claim 1, the media files being stored in a plurality of storage libraries, and wherein the step of generating a catalog further comprises the step of retrieving the list of storage libraries the media files are stored in.
4. The method of claim 3, wherein the step of generating the catalog further comprising the steps of:
- associating a library identifierforeach storage library, and, -associating for each media file entry the library identifier wherein the content data forthe media file can be retrieved.
5. The method of claim 4, wherein the step of gene rating the catalog further comprise s the step of collecting the type of media file for each media file entry.
6. The method of claim 1, wherein the media files are stored in a plurality of storage libraries, a triggering event forthe step of generating the catalog being at least one of:
-the change of a media file address, -the addition of a media file to a storage library,
-the removalofa media file to a storage library,
-the addition of a storage library,
-the removalofa storage library
-a periodic update of the catalog.
7. The method of claim 6, wherein the step of generating the catalog is carried out forthe media files and storage libraries that caused the triggering event.
8. A system to manage media files, each media file being characterized by a metadata and a data content to be rendered, said system comprising:
- a medium storage to store a catalog of media file entries, each media file entry corresponding to a media file and comprising:
-the media file metadata of said media file, -a unique identifier for said media file based at least on part of said media file metadata,
- an up-to-date address for retrieval of said data content of said media file, - a playlist processor operationally coupled to the medium storage and arranged to generate a playlist of media files selected in the catalog, said playlist comprising at least foreach selected media file its unique identifier, wherein the data content of at least one of the selected media files of the playlist is retrieved by searching in the catalog the up-to-date address corresponding to its unique identifier.
9. The system of claim 8, wherein the media files are stored in a plurality of storage libraries, the system furthe r c o mp rising a catalog processor operatively coupled to the medium storage, said processorbeing arranged to : -retrieve the media files on said plurality of storage libraries,
- compute the unique identifier,
- store the catalog of media file entries.
10. The syste m o f c Ia im 9, whe re in the catalog proce sso r is furthe r a rra ng e d to retrieve the data content of each selected media file of the playlist by searching in the catalog the up-to-date address corresponding to the unique identifier.
11. The system of claim 8, wherein the unique identifier is computed further taking into account the data content of the media fie.
12. The system of claim 9, wherein each library is associated with a library identifier, and wherein the processor is further arranged to :
-associate foreach media file entry the library identifier wherein the content data forthe media file can be retrieved.
13. The system of claim 8, wherein the media files are stored in a plurality of storage libraries, the system comprising a catalog processor arranged to generate the catalog upon the occurrence of a triggering event, said triggering eventbeing at least one of:
-the change of a media file address, -the addition of a media file to a storage library, -the removalofa media file to a storage library, -the addition of a storage library, - the removalofa storage library, -a periodic update of the catalog.
14. The system of claim 13, the catalog processor being further arranged to generate the catalog forthe media files and storage libraries that caused the triggering event.
15. An application embodied on a computer readable medium arranged to manage media files, the application comprising: -a portion to generate a catalog of media file entries, each media file entry corresponding to a media fie, said portion of generating a catalog comprising fo r e a c h me dia file e ntry a p o rtio n to :
- collect the media file metadata of said media fie,
- collect an up-to-date address for retrieval of said data content of said media fie,
- c ompute a unique identifier at least on part of said media fie metadata, -a portion to generate a p Ia ylist from media fie e ntrie s se Ie c te d in said catalog, said playlist comprising at least for each selected media fie entry its unique id e ntifie r, and, for at least one of the selected media file entries of said playlist a portion to : - search its unique id e ntifie r in the catalog,
-retrieve the corresponding data content from the up-to-date address associated to said unique identifier, - render said data content.
PCT/IB2007/055405 2006-12-28 2007-12-20 Media file server WO2008081415A2 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US88225406P 2006-12-28 2006-12-28
US60/882,254 2006-12-28

Publications (2)

Publication Number Publication Date
WO2008081415A2 true WO2008081415A2 (en) 2008-07-10
WO2008081415A3 WO2008081415A3 (en) 2008-12-31

Family

ID=39589069

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2007/055405 WO2008081415A2 (en) 2006-12-28 2007-12-20 Media file server

Country Status (1)

Country Link
WO (1) WO2008081415A2 (en)

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010078281A3 (en) * 2008-12-31 2011-01-13 Apple Inc. Method for streaming multimedia data over a non-streaming protocol
US8099476B2 (en) 2008-12-31 2012-01-17 Apple Inc. Updatable real-time or near real-time streaming
US8156089B2 (en) 2008-12-31 2012-04-10 Apple, Inc. Real-time or near real-time streaming with compressed playlists
US8260877B2 (en) 2008-12-31 2012-09-04 Apple Inc. Variant streams for real-time or near real-time streaming to provide failover protection
US8560642B2 (en) 2010-04-01 2013-10-15 Apple Inc. Real-time or near real-time streaming
US8578272B2 (en) 2008-12-31 2013-11-05 Apple Inc. Real-time or near real-time streaming
US8805963B2 (en) 2010-04-01 2014-08-12 Apple Inc. Real-time or near real-time streaming
US8843586B2 (en) 2011-06-03 2014-09-23 Apple Inc. Playlists for real-time or near real-time streaming
US8856283B2 (en) 2011-06-03 2014-10-07 Apple Inc. Playlists for real-time or near real-time streaming
US8892691B2 (en) 2010-04-07 2014-11-18 Apple Inc. Real-time or near real-time streaming
US9729830B2 (en) 2010-04-01 2017-08-08 Apple Inc. Real-time or near real-time streaming

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001079964A2 (en) * 2000-04-14 2001-10-25 Realnetworks, Inc. System and method of managing metadata
US20030182255A1 (en) * 2002-03-21 2003-09-25 Daniel Plastina Methods and systems for repairing playlists
US20040078383A1 (en) * 2002-10-16 2004-04-22 Microsoft Corporation Navigating media content via groups within a playlist
US20060026634A1 (en) * 2002-10-16 2006-02-02 Microsoft Corporation Creating standardized playlists and maintaining coherency
US20060195480A1 (en) * 2005-02-28 2006-08-31 Michael Spiegelman User interface for sharing and searching playlists

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001079964A2 (en) * 2000-04-14 2001-10-25 Realnetworks, Inc. System and method of managing metadata
US20030182255A1 (en) * 2002-03-21 2003-09-25 Daniel Plastina Methods and systems for repairing playlists
US20040078383A1 (en) * 2002-10-16 2004-04-22 Microsoft Corporation Navigating media content via groups within a playlist
US20060026634A1 (en) * 2002-10-16 2006-02-02 Microsoft Corporation Creating standardized playlists and maintaining coherency
US20060195480A1 (en) * 2005-02-28 2006-08-31 Michael Spiegelman User interface for sharing and searching playlists

Cited By (28)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8762351B2 (en) 2008-12-31 2014-06-24 Apple Inc. Real-time or near real-time streaming with compressed playlists
US8260877B2 (en) 2008-12-31 2012-09-04 Apple Inc. Variant streams for real-time or near real-time streaming to provide failover protection
EP3300372A3 (en) * 2008-12-31 2018-05-02 Apple Inc. Streaming multimedia data over a non-streaming protocol
US8156089B2 (en) 2008-12-31 2012-04-10 Apple, Inc. Real-time or near real-time streaming with compressed playlists
US10977330B2 (en) 2008-12-31 2021-04-13 Apple Inc. Playlists for real-time or near real-time streaming
US8280863B2 (en) 2008-12-31 2012-10-02 Apple Inc. Real-time or near real-time streaming with compressed playlists
US8301725B2 (en) 2008-12-31 2012-10-30 Apple Inc. Variant streams for real-time or near real-time streaming
WO2010078281A3 (en) * 2008-12-31 2011-01-13 Apple Inc. Method for streaming multimedia data over a non-streaming protocol
US9558282B2 (en) 2008-12-31 2017-01-31 Apple Inc. Playlists for real-time or near real-time streaming
US8578272B2 (en) 2008-12-31 2013-11-05 Apple Inc. Real-time or near real-time streaming
US8639832B2 (en) 2008-12-31 2014-01-28 Apple Inc. Variant streams for real-time or near real-time streaming to provide failover protection
US8650192B2 (en) 2008-12-31 2014-02-11 Apple Inc. Playlists for real-time or near real-time streaming
US8099473B2 (en) 2008-12-31 2012-01-17 Apple Inc. Variant streams for real-time or near real-time streaming
US8099476B2 (en) 2008-12-31 2012-01-17 Apple Inc. Updatable real-time or near real-time streaming
EP2475149A3 (en) * 2008-12-31 2013-06-05 Apple Inc. Method for streaming multimedia data over a non-streaming protocol
CN102611701B (en) * 2008-12-31 2015-07-15 苹果公司 Method for streaming multimedia data over a non-streaming protocol
US11019309B2 (en) 2010-04-01 2021-05-25 Apple Inc. Real-time or near real-time streaming
US8560642B2 (en) 2010-04-01 2013-10-15 Apple Inc. Real-time or near real-time streaming
US9729830B2 (en) 2010-04-01 2017-08-08 Apple Inc. Real-time or near real-time streaming
US8805963B2 (en) 2010-04-01 2014-08-12 Apple Inc. Real-time or near real-time streaming
US10693930B2 (en) 2010-04-01 2020-06-23 Apple Inc. Real-time or near real-time streaming
US10044779B2 (en) 2010-04-01 2018-08-07 Apple Inc. Real-time or near real-time streaming
US8892691B2 (en) 2010-04-07 2014-11-18 Apple Inc. Real-time or near real-time streaming
US9531779B2 (en) 2010-04-07 2016-12-27 Apple Inc. Real-time or near real-time streaming
US10523726B2 (en) 2010-04-07 2019-12-31 Apple Inc. Real-time or near real-time streaming
US8843586B2 (en) 2011-06-03 2014-09-23 Apple Inc. Playlists for real-time or near real-time streaming
US9832245B2 (en) 2011-06-03 2017-11-28 Apple Inc. Playlists for real-time or near real-time streaming
US8856283B2 (en) 2011-06-03 2014-10-07 Apple Inc. Playlists for real-time or near real-time streaming

Also Published As

Publication number Publication date
WO2008081415A3 (en) 2008-12-31

Similar Documents

Publication Publication Date Title
WO2008081415A2 (en) Media file server
JP4347223B2 (en) System and method for annotating multimodal characteristics in multimedia documents
JP5214969B2 (en) Information recording medium recording metadata supporting multi-language, and metadata processing method and system
US7966362B2 (en) Management of podcasts
CN101256811B (en) Apparatus and method for producing play list
US20080077594A1 (en) Providing a user access to data files distributed in a plurality of different types of user devices
US8972458B2 (en) Systems and methods for comments aggregation and carryover in word pages
US7953777B2 (en) Method and system for retrieving and organizing web media
US20140245147A1 (en) Active Playlist Having Dynamic Media Item Groups
US20220035858A1 (en) Generating playlists using calendar, location and event data
US20070038672A1 (en) Single action media playlist generation
US20060155952A1 (en) Memory management system and method using a hash table
US9547698B2 (en) Determining media consumption preferences
CN101256809B (en) Storage medium storing audio-visual data including metadata, reproducing apparatus, and method of searching for audio-visual data using the metadata
CN101128880A (en) Retrieving content items for a playlist based on universal content ID
CN113778295B (en) Book recommendation method and device, computer equipment and storage medium
US20150081690A1 (en) Network sourced enrichment and categorization of media content
US20120197946A1 (en) Database schema complexity reduction
EP2515248A1 (en) Database manager and method and computer program for managing a database
US20100312808A1 (en) Method and apparatus for organizing media data in a database
KR20060025100A (en) Information storage medium recording meta data supporting multi-language and manipulation method thereof
CN105468614B (en) Cataloguing method and device
JP5440570B2 (en) Music playback system, music playback method, music playback device, and music playback program
JP2005166206A (en) Information recording and reproduction equipment and information providing system
Holmberg et al. MUSICSTRANDSTM: A PLATFORM FOR DISCOVERING AND EXPLORING MUSIC

Legal Events

Date Code Title Description
NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 07870489

Country of ref document: EP

Kind code of ref document: A2