Audible metadata

This disclosure describes systems and methods for audibly presenting metadata. Audibly presentable metadata is referred to as audible metadata. Audible metadata may be associated with one or more media objects. In one embodiment, audible metadata is pre-recorded requiring little or no processing before it can be rendered. In another embodiment, audible metadata is text, and a text-to-speech conversion device may be used to convert the text into renderable audible metadata. Audible metadata may be rendered at any point before or after rendering of a media object, or may be rendered during rendering of a media object via a dynamic user request.

BACKGROUND

Music, videos, and other media objects are often accompanied by or associated with metadata, or data describing the media objects. Metadata may include information identifying the associated media objects, artists, authors, year of production or publication, genres, etc. Metadata is often displayed by certain media players, such as IPOD and WINDOWS MEDIA PLAYER, to assist users in organizing and recognizing media objects.

For instance, the common MPEG-1 Audio Layer 3 or MP3 format of songs, contains a tag or set of metadata that indicates the song title, track number, artist, album, year of publication, genre, and/or other information describing the MP3. A tag may also include album art comprising such file formats as .jpg and .bmp. The most widespread standard audio tag formats are ID3v1 and ID3v2, and the more recently introduced APEv2. ID3v1 and ID3v2 tags are supported in software such as ITUNES, WINDOWS MEDIA Player, WINAMP, YME, MUSICMATCH and hardware players like APPLE's IPOD, Creative Zen, Toshiba Gigabeat and SONY's WALKMAN. The ID3v2 tag contains up to 256 megabytes of data which can include text-based descriptions of a given song as well as pictures.

Devices and software able to render MP3s are often also able to recognize metadata and display the metdadata. For instance, the song titles, genre descriptions, etc. displayed in the ITUNES and WINDOWS MEDIA Player graphical user interfaces (GUIs) are rendered from metadata embedded in MP3s or retrieved from remote servers. Another metadata format is MPEG-7, a format used to encode data about other media formats, often video formats such as MPEG-1, MPEG-2, MPEG-3, and MPEG-4.

SUMMARY

Systems and methods for audibly presenting metadata are disclosed. Metadata, associated with a media object, can be accessed before, during, or after the rendering of a media object, and the metadata can be rendered as an audible output by a media player. In one embodiment, while the media player renders the media object, an audible metadata module can monitor for a user command to render audible metadata. Upon receiving a request for audible metadata, the audible metadata module can access metadata for the current media object and, if necessary, convert it to a form that the media player can render. In another embodiment, the audible metadata module receives a pre-set user request for audible metadata, and proceeds to access and/or identify audible metadata before or after the media object is rendered. In one embodiment the audible metadata takes the initial form of text, and a text-to-speech module produces an audio clip from the text which can be rendered by the media player.

One aspect of the disclosure is a method that includes analyzing a media object to identify metadata associated with the media object. The method also includes analyzing said metadata to identify audible metadata. The format of the audible metadata is identified, and if the format is not of a desired format, then the audible metadata is converted to the desired format.

Another aspect of the disclosure is a system wherein the media object and audible metadata are handled by separate modules: the media player module and the audible metadata module respectively. The media player module accesses and renders the media object, while the audible metadata module accesses metadata associated with the media object and renders an audible form of the metadata to the user.

Yet, another aspect of the disclosure is a method that identifies a relationship between a media object and metadata, identifies audible metadata based on the metadata, associates the audible metadata with the media object, and makes the audible metadata available to a media player.

Another aspect of the disclosure includes a computer readable medium that stores computer data in machine readable form. The computer readable medium includes computer code for receiving a command to render a renderable media object. The renderable media object includes renderable media object data and information identifying metadata associated with the renderable media object. The metadata identifies audio data, different than the renderable media object data, the audio data being audible metadata associated with the media object.

Another aspect of the disclosure includes a method wherein a media object request is received and the media object is accessed. Metadata associated with the media object is accessed, and audible metadata is identified. Finally, the media object and audible metadata are rendered for audible perception.

In another aspect of the disclosure, a media object includes a content portion, a metadata portion, and an audible metadata portion. When the audible metadata portion is rendered via a media player it provides audible information about the content portion.

These and various other features as well as advantages will be apparent from a reading of the following detailed description and a review of the associated drawings. Additional features are set forth in the description which follows, and in part will be apparent from the description, or may be learned by practice of the described embodiments. The benefits and features will be realized and attained by the structure particularly pointed out in the written description and claims hereof as well as the appended drawings.

DETAILED DESCRIPTION

The following definitions of a database, computer-readable media, and computing device will clarify the detailed description that follows the definitions. For the purposes of this disclosure, a database is one or more mass storage devices in which media objects and audible metadata may be stored and from which they may be retrieved. Storage may be volatile (referred to as “caching”) or non-volatile (e.g. storage on a personal computer hard drive or non-volatile random access memory). The mass storage device includes some form of computer-readable media.

Computer-readable media include volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage of information such as computer-readable instructions, data structures, program modules or other data. Computer-readable media includes, but is not limited to, RAM, ROM, EPROM, EEPROM, flash memory or other solid state memory technology, CD-ROM, DVD, or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by a computing device.

A computing device includes a processor and memory for storing and executing program code, data and software. Computing devices may be provided with operating systems that allow the execution of software applications in order to manipulate data. Personal computers, PDAs, wireless devices, cell phones, internet appliances, media players, home theater systems, and media centers are several non-limiting examples of computing devices.

This disclosure describes systems and methods for audibly presenting metadata, referred to as audible metadata. Audible metadata may describe one or more media objects and may be audibly renderable by a media player. For example, audible metadata may be embedded in an MP3 file and rendered before rendering the MP3 data content, for example the encoded song, in order to audibly present metadata to the user. Examples of audible metadata include media object title, artist, genre, number of times the media object has been rendered, rendering duration, and/or the elapsed time since rendering began.

In one embodiment, audible metadata may include pre-recorded audio data. For instance, audible metadata, such as song title, album title, or artist name may be spoken and recorded in .MP3, .WAV, or other audio formats. Pre-recorded audible metadata may be rendered by a media player or may require processing.

In another embodiment, audible metadata may include text. Audible metadata as text may require a media player able to convert text into a renderable form. Alternatively, a text-to-speech module may convert text into a data structure that is renderable by a media player.

In one embodiment, audible metadata may be embedded in the media object. Embedded in the media object means that the audible metadata is contained within the data structure of the media object. For instance, just as the tag or metadata of an MP3 is embedded in an MP3 data structure, audible metadata may be embedded in an MP3 as an audible metadata tag. Alternatively, the audible metadata may be appended to the tag of an MP3. Embedded audible metadata may also include audible metadata that is appended to the beginning or end of a media object so that these two objects are included in a single file.

In another embodiment, audible metadata is a distinct file from the media object. For instance, the media object and audible metadata may be stored on the same computer hard drive, but as separate files. The media object and audible metadata may also reside on separate hard drives within a single computer. At the same time, the media object may reside on a computer readable medium such as a compact disc (CD), while the audible metadata resides on a computer readable medium residing on a device such as a computer. For example, the media object may reside on a CD, while the audible metadata resides on a remote server. In another example, the media may object reside on a computer while the audible metadata may reside on a remote server. In one non-limiting example, audible metadata may be stored on a server, and when a listener, listening to a song via internet radio, requests audible metadata, the server can transmit the audible metadata to the listener and the media player can render the audible metadata along with the song, preferably at the beginning or end of the song but it is contemplated that a user may request the audible metadata be rendered at any point.

FIG. 1illustrates an example of an embodiment depicting basic elements of a system100for audibly rendering audible metadata. A user may request a media object102along with associated audible metadata104. The media playback system110includes elements capable of accessing the media object102and audible metadata104, identifying the audible metadata type, and rendering the media object102and audible metadata104. More particularly, an audible metadata module108may access the media object102and audible metadata104, and identify the audible metadata104type. A media player112may render the media object102and the audible metadata104.

Rendering, for the purpose of this disclosure, generally refers to the process (or a plurality of processes) whereby a media player112converts a media object or audible metadata from an electronic form, typically as digital data, into a perceptible form, for visual, audible or tactile perception by a user. Audible metadata, as the name implies, is intended to be rendered audibly to a user.

The media object102includes data, such as a file, that can be rendered by a media player. The most common media objects102are either audio or video data or files. Audio media object formats include but are not limited to MP3 (also known as MPEG-1 Audio Layer 2), WINDOWS MEDIA audio (WMA), Advanced Audio Coding (AAC, and also known as MPEG-2 Part 7 and MPEG-4 Part 3), Waveform Audio File Format (WAV), SUPER AUDIO CD, DVD-A, and MIDI. Video formats include but are not limited to MPEG-1, MPEG-2, MPEG-3, MPEG-4. Some common media objects include songs, podcasts, spoken quotes, audio clips, music videos, movies, books, advertisements, and video clips. The media object102may also encompass a playlist of media objects such as songs, movies, or video clip, or may encompass a photo or a slide show. The media object102may also be streaming media such as for example, internet radio (e.g. YAHOO! LAUNCHCAST, Live365), satellite radio (e.g. SIRIUS SATELLITE RADIO, XM SATELLITE RADIO), or a video stream (e.g. YOUTUBE, Break.com).

Streaming media, for the purposes of this disclosure, is a type of media that is rendered as quickly as practicable while a user device is receiving the content from a server in order to reduce the delay between the user request for the content and the initiation of the rendering of the content to the user. Streaming media may also include prefetching media, in which data is cached in anticipation of being transmitted to the sender. Before or during rendering streaming media, the user may or may not store a local copy of the received media content depending on the system.

The audible metadata104is as described earlier.

The media playback system110is a computing device, such as for example, a personal computer (PC), web-enabled personal data assistant (PDA), a smart phone, a CD or DVD player, or a laptop computer. The media playback system110may also be a purpose-built media device such as an IPOD. The media playback system110includes all elements that may be used to access, identify, and render audible metadata and may include an audible metadata module108, a TTS module114, and/or a media player112.

The audible metadata module108encompasses software and/or hardware that may access audible metadata104and identify the audible metadata104type. Accessing includes locating audible metadata104. Identifying includes determining whether the audible metadata104is text or pre-recorded audio. Identifying also includes preparing audible metadata for rendering. For audible metadata104as text, a text-to-speech (TTS) module114may be used. A TTS module114may operate by concatenating pieces of pre-recorded speech or may use a model of the human vocal system to completely synthesize desired sounds. Examples include APPLE PlainTalk, Festival Speech Synthesis System, Praat, Text2Speech, and Vocoder. The TTS module114may reside in hardware or software.

In addition to accessing and identifying audible metadata, the audible metadata module108may, in an embodiment, track the number of times a user has rendered a particular media object102and its associated metadata104, and issue commands to discontinue metadata104rendering after a pre-set number of renders. This embodiment overcomes the problem of a user getting to know audible metadata so well that continued audible metadata rendering is not desired. The pre-set number of renders may have a default value and/or be customized by one or more users. Alternatively, discontinuation of metadata104rendering may be a function of the total amount of time that metadata104has been rendered. For example, instead of discontinuing metadata104rendering after 10 instances, rendering may be discontinued after metadata104has been rendered for a total of 100 seconds. Similarly, discontinuation may be a function of a decay function that takes into account both the number of times that metadata104has been rendered and the total time that metadata104has been rendered. In another embodiment, the rendering of metadata104may be tracked and information describing rendering of metadata104may be stored. An algorithm may analyze this information and determine a decay function describing the user's interest in having metadata104rendered. For example, tracking information may show that the user initially rendered metadata104every time that the media object102was rendered. Over time, however, the user less frequently rendered metadata104. The algorithm may extrapolate the trend in rendering and determine a threshold number of renderings after which the algorithm predicts that the user will no longer want to hear metadata104rendered, and will therefore discontinue rendering after the threshold number is reached.

For the purposes of this disclosure, the media player112is hardware, software, or some combination of the two that renders media objects and audible metadata. If a media player112includes software, then it is also possible for the software to be encoded in hardware such as is seen with portable media players like the IPOD. For the purposes of this disclosure, hardware with an encoded media player will also be referred to as a media player112, and used interchangeably with element110, as would be understood by a person of skill in the art. In the embodiment shown, the media player112/media playback system110may be a portable media player, such as an IPOD, CREATIVE ZEN, or IPHONE; an application on a personal computing device, such as WINDOWS MEDIA Player, or ITUNES; or a wireless receiver, such as a WALKMAN, IPHONE, SiriusS50, or Starmate, or any other hardware, software of firmware, alone or in combination, that functions to convert digital media into human perceptible form. The media player112(or system110) may also be a module of a system that comprises other components.

FIG. 2is a flow chart representing an example of an embodiment of a method for accessing and rendering a media object and audible metadata. In the method200, a request for the media object is received in a receive request operation202, and the media object and associated audible metadata may be accessed in an access metadata operation204. The audible metadata type may be identified and conversion to renderable audible metadata performed if necessary in an identify audible metadata operation206. The audible metadata along with the media object may be rendered in a render operation208.

A more detailed description of the method200follows. A request for a media object may be initiated in the receive request operation202. For instance, a user may select a play button on a media playback system interface, wherein the play button initiates a request for a media object. At the same time, a playlist may be displayed on a media playback system and a user may select a particular media object in the playlist, or the device may be set to randomly play media from a library of media. For example, in software-based media players, a user moves a cursor over the description of a media object and selects the media object either by single or double clicking on the media object description. This selection action initiates a request for the selected media object in a receive request operation202. A request for a media object may also be non-user initiated. For instance, a media player may have an alarm setting that initiates a request for a media object at a pre-set time. A media player may also initiate an automatic request for a media object when a CD or DVD is inserted. For example, WINDOWS MEDIA Player and ITUNES may automatically begin rendering songs on a CD or movies on a DVD when a CD or DVD is inserted into the DVD/CD reader of a personal computer.

The method200also includes an access media object and associated metadata operation204. The access operation204includes accessing the media object and accessing the audible metadata for the requested media object. In an embodiment, accessing the audible metadata may include locating the audible metadata. As noted previously, some embodiments envision the audible metadata existing as an embedded element in a media object or as a separate file in any number of locations. Locating the audible metadata may include searching inside the media object for embedded audible metadata, and/or searching in other locations for audible metadata that is stored separate from the associated media object. For example, the audible metadata module may first search an MP3 for indicators that audible metadata is embedded in the MP3. If the audible metadata is not found there, then the audible metadata module may search the computer hard drive where the media object is stored, for the requested audible metadata. If the audible metadata is not found on the hard drive, then the audible metadata module may search remote servers via an Internet connection. The audible metadata module may search in any number of locations as well as search such locations in any order. Storing and accessing the audible metadata separate from the media object permits media objects that are already encoded and stored or accessible by a user to not need to be modified in any way to take advantage of the benefits of audible metadata. In another embodiment, the audible metadata module is pre-configured to read data embedded in the media object directing the audible metadata module to search a specified location for the audible metadata. For instance, an internet protocol address, such as a uniform recourse location (URL), may be embedded in an MP3. The audible metadata module may be pre-configured to look for this embedded address, and use the address to access audible metadata via the Internet. In another example, code may be embedded in a MPEG-7 that guides the audible metadata module to a location on a database of a portable media player where associated audible metadata can be accessed.

The disclosed method also includes an identify audible metadata operation206. The type of audible metadata may be determined, and the audible metadata may be converted into a renderable form in the operation206. In another embodiment, data indicating the type of audible metadata may be stored along with the audible metadata, thus simplifying the identify operation206. In some embodiments, the conversion operation may not be needed as discussed in detail with reference toFIG. 3. As previously noted, the audible metadata will preferably either be text or pre-recorded audio. Determining the audible metadata type may be accomplished via the audible metadata module reading an indicator on the audible metadata that correlates to one of the two audible metadata types. For instance, the first bit of metadata may be a one or a zero, with one corresponding to text-based metadata and a zero indicating audible metadata, and the audible metadata module may determine the metadata type by reading and analyzing this bit. At the same time, the audible metadata module may scan the metadata and determine based on the type of data structure whether text-based or audible metadata exists. Other methods for determining the type of metadata may also be used in the identify operation206.

The method200also includes a render media object and audible metadata operation208. The operation208includes rendering both the media object and the audible metadata. The audible metadata may be rendered before or after the media object, or even during should a user or media supplier deem that desirable. There may be a finite time span between rendering of the media object and audible metadata or no time may elapse. In another embodiment, the audible metadata may be rendered both during the media object rendering and before/after the media object rendering. For instance, the audible metadata may begin rendering before a media object renders, and a finite time after the media object begins to render, the audible metadata stops rendering. The same situation may be seen with the audible metadata rendering overlapping the end of a media object render along with a finite time after the media object has ceased to render.

For embodiments in which the audible metadata and media object are rendered simultaneously, the rendered audio amplitude, or volume, of each may be varied. For example, the media object volume may be rapidly reduced when the rendering of the audible metadata begins. This enhances the listener's ability to clearly hear the audible metadata. When the rendering of the audible metadata is complete, the volume may rapidly rise to the original volume. In another embodiment, at the start of or just before the audible metadata is rendered, the media object rendering may be turned off or interrupted until rendering of audible metadata is complete or near completion. In yet another embodiment, the media object rendering may be suspended until the audible metadata has been rendered. In other embodiments, the rate at which the volume changes at the beginning and end of audible metadata rendering may be fast, slow, or any rate in between. The volume may also change instantaneously. It is also envisioned that the volume could gradually change throughout the rendering of the audible metadata, or that the rate of change may not be constant. An exponential rate of volume change is one example.

FIG. 3illustrates an embodiment of a method for performing the identify audible metadata operation. In the illustrated embodiment, the identify audible metadata step206includes a determination of audible metadata type302as well as a processing step wherein audible metadata is converted to a renderable form. The audible metadata module may perform the audible metadata type determination302. Alternatively, if metadata is text-based, then a first converting step304uses the text-to-speech module to convert the audible metadata to renderable form. If audible metadata is pre-recorded, then a second converting step306may prepare the audible metadata for rendering. For instance, a media object may be a first MP3. Audible metadata, in the form of the audio data from a second MP3, may be embedded in the tag of the first MP3. The embedded second MP3 may lack code that usually precedes an MP3 file. Without this code, a conventional media player is unable to render the embedded second MP3. The audible metadata module108on the other hand, may recognize the embedded second MP3, and convert it to a form that is renderable by a media player in the convert to renderable audible metadata operation306. In some embodiments, pre-recorded audible metadata may be renderable, and as such the operation306may not be needed.

If audible metadata is text, then a convert to renderable audible metadata using TTS operation304may be used to generate renderable audible metadata. As discussed previously, the TTS module can perform such a conversion.

In an embodiment that is not illustrated, the identify audible metadata operation206may include appending audible metadata to the media object. For instance, audible metadata may be appended to an MP3 file, so that when rendered, the audible metadata and media object render as a continuous audio clip. In another example, a playlist may be generated wherein audible metadata is added before or after the associated media object, or after a group of media objects (e.g. identifying the previously rendered three songs in a playlist).

FIG. 4is a flow chart of an embodiment of a method for accessing, identifying, and rendering audible metadata. For simplification, in the method400and all subsequent embodiments, the media object is a song. It should be noted, that this does not limit the present disclosure to embodiments in which the media object is a song, as discussed above a media object can be any of a myriad of digital content types, including for example video, audio, spoken word, images, etc.

A song request is received in a receive request for media object operation402, as for instance when a play button on a media device such as an IPOD is depressed or via selection of an onscreen button in a computing application such as WINDOWS MEDIA Player or ITUNES. The song request may be also be initiated by a computing device such as when a media player's wake-up alarm initiates or a shuffle or random play mode is invoked, or when a playlist is pushed or loaded into a device, or when an internet or satellite radio station is navigated to.

The method also includes an access song (or other media object) and metadata operation404. Similarly to the discussion ofFIG. 2, accessing includes locating the metadata. The method400includes an optional determination operation410in which the system determines if audible metadata should be automatically rendered when rendering the requested song (e.g. if a user elects not to have audible metadata rendered). If the determination operation410determines that audible metadata is not to be rendered, then the method400ends and the song is rendered without audible metadata. If the determination operation410determines that audible metadata is to be rendered, then an identify audible metadata operation406and render audible metadata operation408are performed. Embodiments of these operations406,408have been previously discussed with reference toFIG. 2.

The determination operation410may make its determination based on a default setting or other information. In an embodiment, a system may provide a user with access to a global audible metadata default setting that allows the user to select if and when audible metadata should be rendered. For example, a user may be able to select a setting that instructs the system to always play audible metadata when possible. Such a global default setting may also allow the user to dictate when, relative to the rendering of the song (i.e., preceding the song, after the song, during the song, etc.), and how the audible metadata is to be rendered.

The disclosed method is not limited to the order presented inFIG. 4. For example, in another embodiment the render audible metadata determination operation410may occur after the audible metadata identify operation406. This order may be preferred in applications where a song is being transmitted to a large number of listeners, such as in a satellite radio network. In a satellite radio network it may be preferable for the audible metadata to be identified at the satellite or at a server transmitting to the satellite, and allow receivers to perform the determination step. Otherwise, the satellite or its server may be responsible for performing the determination operation410for every receiver—an exceedingly cumbersome process.

FIG. 5is a flow chart of an embodiment of a method for accessing, identifying, and rendering audible metadata wherein a request for audible metadata is received during media object rendering. In the method500, a song may be being rendered or may simply be selected by the user. The method500begins in a standby state, waiting for the user to request audible metadata. This is illustrated by the waiting operation501. The user request may be made through hardware or software based selection. This may include depression of a physical button, toggling of a switch, heat-activated touch sensor, voice-activated selection, selection of a software based button or checkbox, or any other means of selection. For instance, a portable media player may be rendering a song, and the audible metadata module continuously or intermittently monitors an audible metadata request button. This situation may arise if, for instance, a user is listening to a song on a portable media player without a display, but wants to know the name and artist of the song. The user pushes an audible metadata request button and initiates a request for audible metadata.

If a user request is made, the request is received in a receive request for audible metadata operation502. Continuing the above-noted example, this step may be manifested in the audible metadata request button being selected and electronics or software associated with the button transmitting an audible metadata request to the audible metadata module.

The method500also includes an access audible metadata operation504, an identify audible metadata operation506, and a render audible metadata operation508as previously described with reference toFIG. 2. Upon rendering, the method500returns to the state of waiting for a user request501.

The request may be generated by and received from various sources. In one embodiment, the request may be made by a computing device. For instance, a system may exist wherein a computing device analyzes a media object that is being rendered and determines that audible metadata should be rendered. In such a situation, the computing device requests the audible metadata during media object rendering.

In another embodiment a method may include a waiting operation501as well as include a determination operation410. For example a user may pre-select audible metadata for rendering via a default selection, but also have the option of requesting audible metadata during media object rendering. Such a need may arise if, for instance, the user does not pre-request audible metadata, but decides during media object rendering, that audible metadata is desired. Alternatively, if the default calls for audible metadata to be rendered, and the user wants to hear the audible metadata a second time during rendering, then the user can request audible metadata without having to restart the song or wait until the song finishes.

FIG. 6illustrates embodiments of a system for accessing, identifying, and rendering audible metadata. With reference toFIG. 6, the media object will again be discussed in terms of a song. The architecture600illustrated is a networked client/server architecture in which a computing device of any type, the client602, issues a song request and an audible metadata request to a remote computing device, the server616, which responds by transmitting the requested song and requested audible metadata to the client602for rendering. The systems and methods described herein are suitable for use with other architectures as discussed in greater detail below. It should also be noted, that in certain embodiments the server616may not be included/necessary, as all elements may be implemented on a user's computing device.

The client602may comprise a media player608, and a graphical user interface (GUI)614presented via a display612. Both the client602and server616may include one or more of the following: an audible metadata module604,624, a text-to-speech module606,626, and a database610,630. In the illustrated architecture600, the client602and server616may be linked via satellite636, wireless link632, or the internet634. One skilled in the art will recognize that the architecture600is not limited to these three forms of links, and that other methods for communicating between a client and server may be used. For instance, the link could be an intranet, or a wireless local network.

In one embodiment the client602requests audible metadata from the server616for a designated song. The server616retrieves audible metadata stored on a server database630and transmits the audible metadata back to the client602. The request may be made as soon as a new song is downloaded to the client602and the metadata may be stored on and retrieved from the local storage thereafter. Alternatively, the request may be made every time the media player608renders the song. For this embodiment embodiment, instead of long-term storage, the metadata may be cached, and subsequently deleted after the song has been rendered or when the media player608is turned off. The server616may also store the audible metadata on the server database630and stream the audible metadata to the media player608without storing the audible metadata on the client602.

In another embodiment, the metadata is text-based, and must be converted to renderable audible metadata. As discussed above, this may be done using a TTS module. The TTS module606may reside with the client602. In this embodiment, when the client602requests audible metadata from the server616, the server616may return text-based audible metadata that the client's TTS module606converts to renderable audible metadata. This audible metadata may be immediately rendered or stored for subsequent rendering. In an alternative embodiment, the TTS module606may also reside on the server616. When the client602requests audible metadata from the server616, the server's TTS module626converts the text-based audible metadata into renderable audible metadata and transmits the audible metadata to the client602. The media player608may render the audible metadata or the audible metadata module604may store the audible metadata for subsequent rendering. In another embodiment, the text-based audible metadata is converted to renderable audible metadata via a TTS module626on the server, and the audible metadata is stored on the server database630to be transmitted at another time. It should be understood that the various elements of the client and server may be sub-elements of each other in other embodiments. For instance, the TTS module606may be a part of the audible metadata module604, the media player608may be a part of the audible metadata module604, or any other combination that is practical.

In an embodiment, the client602may be a wireless receiver such as a satellite radio receiver. If the client has a database610, then the audible metadata may be stored upon receipt from the satellite636. However, in some cases the client602will not have a database610and the audible metadata may be rendered without being stored on the client602. Other wireless transmitters632may be substituted for the satellite636in this embodiment.

In another embodiment, a song may be stored on the client602having been retrieved from a computer readable medium such as a compact disc or a flash drive or been previously stored or ripped. In this embodiment the song may not be retrieved with associated metadata. However, the audible metadata module604may recognize the absence of metadata, and send a request to the server616for audible metadata. This may happen as soon as the song is stored on the client database610, may be performed when a request to render the song is made, or may be performed during song rendering.

In another embodiment there is only a client602. This situation may arise, if a compact disc (CD) is used to retrieve songs and the songs on the CD include associated metadata. In this embodiment, the metadata is stored on the client database610for later retrieval, and thus metadata retrieval from a server may not be necessary. Text-based metadata may be rendered after audible metadata identification using a TTS module606, and audible metadata may be processed by the audible metadata module604or rendered without processing.

In yet another embodiment, a request for a song and audible metadata is received by the server616, and the server616accesses the requested song and audible metadata and combines the two. The combination is returned to the client602and rendered either as two consecutive audio clips in a playlist or as a single event with the audible metadata preceding or following rendering of the song. This embodiment can also be applied to a client-only situation in which the client602performs the combining action or to a client-server system in which the combination is streaming media.

In another embodiment, the client is a portable media player. The portable media player has a database610, audible metadata module604, and TTS module606. The client database610is populated with media objects and associated metadata through either a link to a server616, or a computer readable medium. Text-based metadata is converted to renderable audible metadata by the TTS module606and rendered by the audible metadata module604, while audible metadata may be processed by the audible metadata module604or may be rendered without processing.

In another embodiment, a TTS module606,626and audible metadata module604,624may reside on both a client602and server616. In this manner, the TTS process and/or audible metadata identification and rendering can be performed at either the server616if the link632,634,636is operating optimally, or at the client602if the link632,634,636is not operating optimally. For instance, while the server-based operation may be preferred, there may be times when the internet connection634prevents the server616from performing the TTS operation. In this situation the TTS module606associated with the client602may perform TTS of metadata until the internet connection634is repaired or resumed. In other situations, the connection632,634,636may simply be less than optimal, such as at periods of high internet traffic, in which case it may be preferable for the operations associated with the TTS module606and/or audible metadata module604to take place on the client602rather than the server616.

FIG. 7is a flow chart representing an embodiment of a method for accessing and rendering a media object and audible metadata. The method700may include an analyze media object operation702, in which a media object is analyzed in order to identify metadata associated with the media object. For example, an audible metadata module may analyze an MP3 data structure, searching for metadata associated with the MP3.

The method700may also include an analyze metadata operation704. In this operation704, metadata is analyzed in order to identify audible metadata. In other words, this operation704identifies audible metadata from the metadata identified in the analyze media object operation702. For instance, an MP3 may include metadata that an audible metadata module has identified. The audible metadata module may then analyze the metadata to identify audible metadata. This may include identifying computer instructions that instruct a computing device as to how to and where to find the audible metadata. Alternatively, the audible metadata may be part of the media object, and analyzing the metadata may show that the audible metadata may be found with or within the media object.

Audible metadata may exist in various formats such as .MP3, .WAV, MIDI, computer code embedded in an audio or video file, and other formats. Without identifying the format, a media player may not be able to operate on or render the audible metadata. As such, the method700may include an identify audible metadata format operation706.

Whether or not audible metadata may be operated on or rendered by the media player, the method700may include a convert audible metadata708operation to handle audible metadata that is not in the desired format. For instance, if audible metadata is code embedded in a first MP3, then the code may be converted into a second MP3 or some other format that a media player may render. Alternatively, a given media player may only render a certain format of audible metadata, yet the audible metadata to be rendered is in another format. As such, the convert audible metadata operation708may convert the audible metadata from the non-renderable format to the renderable format.

FIG. 8is an embodiment of a system including a media player module and an audible metadata module. In the system800the media player module802accesses and renders the media object812, while the audible metadata module804accesses metadata814associated with the media object812and renders an audible form of the metadata814to the user. In one embodiment the system800may include a metadata retrieval module in communication with a remote system. The metadata retrieval module may be able to locate and retrieve metadata if the metadata is not stored on a local system.

FIG. 9is a flow chart representing an embodiment of a method for accessing and rendering a media object and audible metadata. In the embodiment shown, the method900may include an identify media object-metadata relationship operation902. In this operation902the relationship between a media object and metadata may be identified. This may include indexing available media objects and metadata and determining which media objects are associated with certain metadata. These relationships may then be available for the media player to access when audible metadata is requested.

In the method900, it may also be desirable to identify audible metadata, and this can be done via an identify audible metadata operation904. This operation904may involve using the metadata to identify the audible metadata. Identifying audible metadata may include locating audible metadata. Identifying may also include determining the audible metadata format.

Although the relationship between the media object and the audible metadata has been determined, the relationships may not be useful to a media player until audible metadata is associated with media objects. Audible metadata may be associated with a media object in an associate audible metadata with media object operation906. In an embodiment, associating media objects and audible metadata may include storing both in the same location so that they may be grouped during access by a media player. In another embodiment, associating may include storing information regarding the association on a computer readable medium, and making the information available for access.

In an embodiment, the method900may include a make audible metadata available to media player operation908allowing the audible metadata to be audibly rendered for a user. To make audible metadata available may include providing the audible metadata to a media player or it may include storing the audible metadata in a location accessible by a media player. This operation908may also include converting audible metadata to a format that is renderable by the media player.

FIG. 10illustrates an embodiment of a media object. In this embodiment, the media object1000may include content1002, metadata1004, and audible metadata1006. Content1002may include audio, visual, or other media that may be provided to a media player for rendering. Metadata1004and audible metadata1006are illustrated as separate entities, however in one embodiment audible metadata1006may be included in metadata1004. In the illustrated embodiment, metadata1004may describe the content1002. For instance, the metadata may be convertible to a format that is audibly renderable by a media player. Alternatively, the metadata may include computer code that when accessed by a media player or audible metadata module, gives rise to text such as media title, artist, or genre being displayed for a user. In one embodiment, metadata1004may instruct a computing device, such as the audible metadata module, to access the audible metadata1006. In another embodiment the audible metadata1006and metadata are associated with the content1002, but are located separately from the media object1000, such as on a remote server.

It should be recognized, that although much of this disclosure has discussed embodiments in which the media object is a song, alternative media objects can be substituted for the song and not change the intent of this disclosure. It should also be noted that the disclosure is not limited to one of the communication links discussed. Various embodiments may include the use of multiple links such as satellite and internet, or wireless and satellite, or any other combination or number of links.

Those skilled in the art will recognize that the methods and systems of the present disclosure may be implemented in many manners and as such are not to be limited by the foregoing exemplary embodiments and examples. For example, modules may be embodied in hardware, software, a combination of the two, or other means. Further, functional elements being performed by single or multiple components, in various combinations of hardware and software or firmware, and individual functions, may be distributed among software applications at either the client or server or both. In this regard, any number of the features of the different embodiments described herein may be combined into single or multiple embodiments, and alternate embodiments having fewer than, or more than, all of the features described herein are possible. Functionality may also be, in whole or in part, distributed among multiple components, in manners now known or to become known. Thus, myriad software/hardware/firmware combinations are possible in achieving the functions, features, interfaces and preferences described herein. Moreover, the scope of the present disclosure covers conventionally known manners for carrying out the described features and functions and interfaces, as well as those variations and modifications that may be made to the hardware or software or firmware components described herein as would be understood by those skilled in the art now and hereafter.

While various embodiments have been described for purposes of this disclosure, such embodiments should not be deemed to limit the teaching of this disclosure to those embodiments. Various changes and modifications may be made to the elements and operations described above to obtain a result that remains within the scope of the systems and processes described in this disclosure. For example, certain audible metadata may be available only after purchase. For instance, audible metadata producers may pre-record audible metadata using well-known personalities or even use the artists/authors of media objects to pre-record audible metadata. This audible metadata may only be acquired through purchase, or via payment of a fee in addition to other fees that may be associated with audible metadata usage.

For example, and with reference toFIG. 6, the client602may comprise a computing device and a portable media player each having a different database. In other words, the client database610ofFIG. 6may be distributed amongst multiple devices. The same holds for the server database630. In another example, the computing device and portable media player may both contain an audible metadata module604,624and/or a text-to-speech module606,626. Another example includes a system wherein audio or visual programming is streamed to the client602, such as streaming music or streaming television programs, the client602stores the contents of the streaming media, and renders the stored contents of the streaming media any number of times and at any time after the storage takes place. Metadata may be included in the stream and the audible metadata module604may render the stream along with the metadata. Alternatively, the stream may not include metadata. In this embodiment, the audible metadata module604will recognize that metadata104is not included in the stream and will retrieve metadata from the server and render the metadata along with the streaming media.

Numerous other changes may be made that will readily suggest themselves to those skilled in the art and which are encompassed in the spirit of the invention disclosed and as defined in the appended claims.