AUTOMATIC HIERARCHICAL CATEGORIZATION OF MUSIC BY METADATA

Abstract

A method, performed by software executing on the processor of a portable music playback device, that automatically files tracks according to hierarchical structure of categories to organize tracks in a logical order. A user interface is utilized to change the hierarchy, view track names, and select tracks for playback or other operations. The user interface uses an overlapping hierarchy of categories. A song title can be accessed in multiple different ways by starting with different categories. A preferred embodiment of the invention uses the top-level categories Albums, Artists, Genres (or styles), and Play Lists. Within the Albums category are names of different albums of songs stored in the device. Within each album are the album tracks, or songs, associated with that album. Navigation is performed by presenting a sequence of display screens for each level of the hierarchy.

Claims

1. (canceled)

2. A handheld electronic device for playing media tracks, comprising: an onboard processor; a display; an audio output; a computer readable medium storing a definition of, a plurality of categories for categorizing said plurality of media tracks, wherein at least a subset of the categories are overlapping, and an ordering of metadata types associated with each category, wherein one or more of the metadata types of the ordering correspond to one or more subcategories of one or more of the categories; the computer readable medium further containing instructions executable by the onboard processor to create an overlapping hierarchical structure having a plurality of branches in a memory of the handheld electronic device by performing operations including, iterating through multiple tracks of a plurality of media tracks stored on the handheld electronic device, wherein the multiple media tracks have corresponding metadata elements stored on the handheld electronic device, wherein the corresponding metadata elements are organized according to a plurality of predefined metadata types, including, for each such track of the multiple media tracks, iterating through each branch of the plurality of branches of the hierarchical structure, wherein the branches correspond to the plurality of categories, for each such track of the multiple media tracks, and for each such branch, using the ordering associated with the category corresponding with such branch and metadata elements corresponding to such media track to traverse such branch and place such media track in the appropriate position in the hierarchical structure; the computer readable medium further containing instructions executable by the onboard processor to present a user interface with first, second, and third sequentially presented display screens on the display of the handheld electronic device for navigating said hierarchical structure, by performing operations including, displaying at least a portion of said plurality of categories in a listing presented in the first display screen, receiving a selection of a category displayed in the first display screen, displaying a plurality of subcategories belonging to the selected category in a listing presented in the second display screen, receiving a selection of a subcategory displayed in the second display screen, displaying a plurality of items belonging to the selected subcategory in a listing presented in the third display screen, and accessing at least one media track based on a selection made in one of the display screens.

3. The handheld electronic device of claim 2, wherein the operations to present a user interface further comprise receiving a selection of at least one item displayed in the third display screen.

4. The handheld electronic device of claim 2, wherein the accessing of at least one media track comprises playing the at least one media track.

5. The handheld electronic device of claim 2, wherein the accessing of at lea one media track comprises adding the at least one media track to a playlist.

6. The handheld electronic device of claim 5, wherein the playlist is an active queue list of songs being played.

7. The handheld electronic device of claim 2, wherein the media tracks comprise audio tracks.

8. The handheld electronic device of claim 2, wherein the accessing of at least one media track is performed in response to receiving a selection of a subcategory displayed in the second display screen, and wherein the accessing comprises playing a plurality of media tracks associated with the selected subcategory.

9. The handheld electronic device of claim 2, wherein the accessing of at least one media track is performed in response to receiving a selection of a subcategory displayed in the second display screen, and wherein the accessing comprises adding a plurality of media tracks associated with the selected subcategory to a playlist.

10. The handheld electronic device of claim 9, wherein the playlist is an active queue list of songs being played.

11. The handheld electronic device of claim 3, wherein the accessing at least one media track is performed in response to receiving the selection of at least one item displayed in the third display screen, and wherein the accessing comprises playing at least one media track associated with the selected at least one item.

12. The handheld electronic device of claim 3, wherein the selected at least one item in the third display screen is associated with a plurality of media tracks, and wherein the accessing at least one media track comprises adding the plurality of media tracks associated with the selected at least one item to a playlist.

13. The handheld electronic device of claim 12, wherein the playlist is an active queue list of songs being played.

14. The handheld electronic device of claim 2, wherein the accessing of at least one media track occurs after displaying the third display screen and in response to receiving an input to revert back to one of the second and first display screens, the second display screen presented sequentially after the third display screen.

15. A handheld electronic device for playing media tracks, comprising: an onboard processor; a display; an audio output; a computer readable medium storing a definition of, a plurality of categories for categorizing said plurality of media tracks, wherein at least a subset of the categories are overlapping, a plurality of media track types, one or more associations specifying which media track types are permitted to be included in each of the categories, and an ordering of metadata types associated with each category, wherein one or more of the metadata types of the ordering correspond to one or more subcategories of one or more of the categories; the computer readable medium further containing instructions executable by the onboard processor to create an overlapping hierarchical structure having a plurality of branches in a memory of the handheld electronic device by performing operations including, iterating through multiple tracks of a plurality of media tracks stored on the handheld electronic device, wherein the multiple media tracks have corresponding metadata elements stored on the handheld electronic device, wherein the corresponding metadata elements are organized according to a plurality of predefined metadata types, including, for each such track of the multiple media tracks, iterating through each branch of the plurality of branches of the hierarchical structure, wherein the branches correspond to the plurality of categories, for each such track of the multiple media tracks, and for each such branch, using the stored definition and metadata elements corresponding to such media track to determine whether such media track belongs in such branch, and for each branch that each such media track belongs in, using the ordering associated with the category corresponding with such branch to traverse such branch and place such media track in the appropriate position in the hierarchical structure; the computer readable medium further containing instructions executable by the onboard processor to present a user interface with first, second, and third sequentially presented display screens on the display of the handheld electronic device for navigating said hierarchical structure, by performing operations including, displaying at least a portion of said plurality of categories in a listing presented in the first display screen, receiving a selection of a category displayed in the first display screen, displaying a plurality of subcategories belonging to the selected category in a listing presented in the second display screen, receiving a selection of a subcategory displayed in the second display screen, displaying a plurality of items belonging to the selected subcategory in a listing presented in the third display screen, and accessing at least one media track based on a selection made in one of the display screens.

16. The handheld electronic device of claim 15, wherein the operations to present a user interface further comprise receiving a selection of at least one item displayed in the third display screen.

17. The handheld electronic device of claim 15, wherein the plurality of media track types identify one or more of: a song media track, a voice media track, a book media track, a video media track, and a playlist of media tracks.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] FIG. 1 is a schematic diagram of a tree structure for hierarchical filing of tracks;

[0021] FIG. 2 is a definition file that specifies the hierarchy depicted in FIG. 1;

[0022] FIG. 3 is a user's view of the hierarchy;

[0023] FIG. 4 is a schematic diagram of a user interface displaying the hierarchical category structure;

[0024] FIG. 5 is a diagram of a file format for storing filed data and file attributes;

[0025] FIG. 6 is a flow chart depicting steps for filing tracks according to the hierarchical tree structure;

[0026] FIG. 7 depicts a tree resulting from searching the tracks;

[0027] FIG. 8 depicts a format for a user interface;

[0028] FIG. 9 illustrates the NOMAD Jukebox and its user interface controls;

[0029] FIG. 10 illustrates a sequence of display screens describing how to navigate to lower levels;

[0030] FIG. 11 illustrates associations among items;

[0031] FIG. 12 shows display screens used to search for a song or other item;

[0032] FIG. 13 illustrates details of different items; and

[0033] FIG. 14 illustrates a playback device coupled to a host computer system.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0034] A preferred embodiment of the invention will now be described in the context of a portable personal player that plays audio files stored in memory. The files may be in MP3, way. or other digital formats.

[0035] In the presently described embodiment, users are able to see the tracks on their player in some organized fashion other than as a single list of tracks. As will be described in more detail below, in one embodiment tracks are sorted utilizing a tree structure having branches labeled according to types of metadata associated with the tracks

[0036] For example, a track recorded as Golden Slumbers by the Beatles that appears on their album Hey Jude might appear as a track under the album Abbey Road as well as a track under the list of tracks by the Beatles. It might appear as a track under the genre Pop Rock as well as Songs from the 60's. Furthermore, the organization can have more complex hierarchies. For example, the category of Pop Rock might contain subcategories British Musicians, American Musicians and Other Musicians. In all cases, the track is automatically filed into all appropriate locations without requiring user interaction.

[0037] In the currently defined embodiment, a tree structure is defined by a file having the following structure.

[0038] The first line of a TreeDef.inf file contains a version number:

[0039] V1.0

[0040] Each subsequent line (at least in v1.0) contains lines of the following format:

[0041] CATEGORY_NAME|TRACK_TYPE_MASK|CATEGORY_STRUCTURE

[0042] CATEGORY_NAMEs are the top-level names of the branch under which tracks are sorted. They include things like Album, Artist, Voice Tracks, All Tracks, etc.

[0043] TRACK_TYPE_MASKs tell which types of tracks are to be filed under this particular branch. The actual value is a hexadecimal numerical value (in 0x format, e.g. 0x01) generated by ORing the following flags together as appropriate:

TABLE-US-00001 enum tTrackType { kTTNothing=0x00, kTTSong=0x01, kTTVoice=0x02, kTTBook=0x04, kTTMacro=0x08, kTTPlaylist=0x10 };

[0044] So, for example, the Album branch has a TRACK_TYPE_MASK of kTTSong, because only songs are filed under that branch, but the All Tracks branch has a TRACK_TYPE_MASK of (kTTSong|kTTVoice|kTTBook).

[0045] Other elements might be added to tTrackType (e.g. kTTVideo) as appropriate.

[0046] CATEGORY_STRUCTUREs tell how to file the songs based on their metadata information. The CATEGORY_STRUCTURE is a string of characters that tell, from left to right, the order of hierarchy. The characters come from the following enum constants:

TABLE-US-00002 enum tFileTag { kFTNone=@, kFTTrackType=T, kFTTitle=N, kFTAudioFile=F, kFTArtist=M, kFTAlbum=L, kFTGenre=G, kFTSource=S, kFTYear=Y, kFTArtistCountry=C };

[0047] Thus, a CATEGORY_STRUCTURE of LN tells to create a subcategory that is a list of Albums, each of which contains a list of Tracks.

[0048] In total, a line like:

[0049] Album|0x01|LN

[0050] Says to create a branch called Album which contains tracks of type kTTSong organized first by album name, and then by track name.

[0051] The following is an example of a tree definition file similar (though not identical) to the hierarchy presented in the Nomad Jukebox product (the B before each FileTag was used to identify that these are basic tags so that we wouldn't run out of letters in the alphabet as we included more complex metadatathus each group of two letters represents a level in the hierarchy):

[0052] V1.0

[0053] Album|0x01|BLBN

[0054] Artist|0x01|BMBN

[0055] Genre|0x01|BGBN

[0056] Voice Tracks|0x02|BSBGBN

[0057] Playlists|0x10|BN

[0058] Macros|0x08|BN

[0059] All Tracks|0x07|BN

[0060] FIG. 1 depicts a hypothetical organization hierarchy. The tree shows how tracks might be listed (as leaves in the tree) after having been organized. Example values for nodes in the tree are shown as well. The same track may appear more than once as a leaf in the tree, as described above, if it fits into multiple categories (e.g. a song that appears on the Abbey Road branch would also appear in the Beatles branch). In the example shown, the first branch contains tracks organized by album. As shown in the example, this music collection contains three tracks from Abbey Road and three tracks from Hits from the 60's. The second branch contains tracks organized by artist, and sub organized by where the artist is from. Thus, a user browsing would first select the Artists branch and then choose between British Artists and American Artists. Finally, they would select the particular artist. In the third branch, all tracks are shown.

[0061] The tree definition file that would specify the hierarchy shown in FIG. 1 is shown in FIG. 2.

[0062] The first line identifies the version of the tree definition file.

[0063] The second line defines the Albums branch. The first part of the line, Albums defines the name of the branch. The second part, 0x01, defines that all musical tracks should be categorized on this branch. The third part, BLBN, defines that the branch lists first the names of all albums (BL) and then tracks on those albums (BN).

[0064] The third line defines the Artists branch. The first part of the line Artists defines the name of the branch. The second part, 0x01, defines that all musical tracks should be categorized on this branch. The third part, BCBMBN, defines that the branch lists first the names of all countries where artists in this collection come from (BC) and under those items, the artists' names (BM), and then tracks by those artists (BN).

[0065] FIG. 3 shows what a user's view of this hierarchy might be if he/she were shown a fully expanded view of the 6-song tree. Notice that each song appears three times, once in each branch.

[0066] In consumer products the tree define file is not edited directly but through a user interface, one example of which is depicted in FIG. 4. An example of a user interface for viewing songs by category and editing the tree structure is depicted in FIG. 4.

[0067] An embodiment of the invention is utilized in the Nomad Jukebox, manufactured by the assignee of the present invention, and described more fully in the copending application, filed on the same date as the present application, entitled System for Selecting and Playing Songs in a Playback Device with a Limited User Interface, (Attny. Docket No. 17002-020800).

[0068] In a preferred embodiment, metadata is associated with each track and includes such information as title, genre, artist name, type, etc. In the preferred embodiment, software stored in a portable player and executed by the onboard processor automatically files each track in the correct category utilizing the associated metadata and the tree define file. The program code can be stored in any computer readable medium including magnetic storage, CD ROM, optical media, or digital data encoded on an electromagnetic signal.

[0069] Thus, the user is automatically provided with a powerful and flexible tool for organizing and categorizing the tracks stored on the portable player.

[0070] If the tracks are formatted in MP3 format the metadata can be stored in ID3 tags included in the MP3 file. In one embodiment of the invention, the tracks are stored in alternate file format including file data and file attributes. The file data is the music track itself and the file attributes part of the file includes fields of arbitrary size which are used to store metadata characterizing the track stored as the file data. Again this metadata includes information about the track such as title, genre, artist name, type, etc.

[0071] There are several advantages to using the alternate file format. Metadata of types not easily included in an ID3 tag can be utilized. Further, the original track format is not changed, so that error correction data such as checksums are valid. Finally, any file format can be used (e.g. WAV, WMA, etc.) because the metadata is stored separately, and thus audio formats that have limited support for metadata can still be stored on the portable player in native format without transcoding. The formatted files are formed by software stored in the portable music player and executed by an on-board processor.

[0072] The metadata for each track is utilized to file each track, using the categories defined in the hierarchical structure as described above, without any input from the user.

[0073] FIG. 5 is a schematic diagram of the alternative file format including file data in the form of an MP3 track, and metadata fields for holding data indicating the name of the album the track is from, the name of the song, the genre of the song, and the type of track.

[0074] A particular embodiment of a file format will now be described. All tracks are created with some set of attributes as shown below:

Definition of TrackInfo Data Field

[0075]

TABLE-US-00003 Field Offset Size Description Attribute Count 0 2 The number of attribute follow for the track Attr 1 type 2 2 Binary = 0, ASCII = 1 Attr 1 name len 4 2 Length of attribute name string Attr1 data len 6 4 Length of attribute data Attr1 Name 10 N Attribute name string Attr 1 Data 10 + N M Attribute data . . . . . . Attr N type Attr 1 name len Attr1 data len Attr1 Name Attr 1 Data

Required Attributes

[0076]

TABLE-US-00004 Attribute Name Value(s) Remarks TITLE ASCII string Required By Jukebox CODEC MP3, WMA, WAV Required By Jukebox TRACK ID DWORD Set By Jukebox ALBUM ASCII string Optional ARTIST ASCII string Optional GENRE ASCII string Optional LENGTH In seconds Optional TRACK SIZE In bytes Optional TRACK NUM 1-n (track within album) Optional [0077] These attributes can be subsequently changeable via a host application, running on a personal computer connected to the portable music player.

[0078] FIG. 6 shows a flow chart of an embodiment the process used to build the hierarchical database of tracks. It starts by iterating through each track, and, for each track, iterating through each branch to find if the track belongs on the branch, and, if so, where. In this case, the term track could refer to any content, e.g. a music track, a spoken word track, or even a video track.

[0079] Also, the hierarchical catalog of tracks can be used to form playlists in a structured manner. For example, if a user wants to hear Jazz and Blues the entire sub-categories can be selected to form one playlist.

[0080] An alternative hierarchical catalog generation technique will now be described. In this alternative embodiment, at system startup and as tracks are added or changed, the hierarchy is generated as an in-memory tree structure. Each track is added to the tree using the categories ALBUM, ARTIST and GENRE.

[0081] The following example shows the algorithm for adding a track. For clarity, only the attributes used by the tree are shown.

TABLE-US-00005 TITLE Free Falling ALBUM Full Moon Fever ARTIST Tom Petty GENRE Rock TRACK NUM 1

[0082] The following function is executed to build the in-memory memory tree.

TABLE-US-00006 Build Tree ( ) For each track, Add Track To Category(Album, Track) Add Track To Category(Artist, Track) Add Track To Category(Genre, Track) End of Build Tree

[0083] FIG. 7 depicts a tree which could result from implementing Build Tree( ) function. Note that Stardust does not have any entries for Album or Artist. The host software running on a computer connected to the portable music player could be utilized to add missing attributes to the Stardust track and, optionally, edit the title attribute. The Build Tree( ) function would then reinsert this track in the correct location in the tree.

[0084] FIG. 8 is an embodiment of a user interface according to another embodiment of the invention. In this example the root node is labeled My Configuration and the Playlist category has been selected and the Playlist subcategory Meddle has been selected. Note that the types of Metadata, in this example, Track Name, Artist, Album, Tempo and Dance, are listed across the top of the screen, and the attribute values for each track are listed in a row across the screen. Various control buttons are displayed to the right of configuration window that facilitate quickly invoking selected processing on a selected track.

[0085] As noted above, a preferred embodiment of the present invention is incorporated into a product manufactured and distributed by Creative Technology, Ltd. The product is called the NOMAD Jukebox. The following description describes further details of the display screens and interface controls.

[0086] FIG. 9 illustrates the NOMAD Jukebox and its user interface controls.

[0087] In FIG. 9, electronic audio device 100 measures about 5.5 wide by 5.5 tall by 1 thick. Display screen 102 is about 2 wide by 1 tall. Display screen 102 includes different regions such as main region 104 and soft button function description region 106.

[0088] Three soft buttons are located at 108; including buttons 110, 112 and 114. The specific command, or function, that any of the soft buttons perform when depressed is indicated by the label in soft button function description region 106. Thus, the function of soft button 112 (as shown in FIG. 9) is open, the function of soft button 114 is search while soft button 110 is currently not assigned a function.

[0089] The other eight buttons on device 100 perform essentially the same functions at all times. In other words, they are not subject to function changes according to soft button function description area 106. These buttons include Library button 116, EAX and System button 118, Skip Backward button 120, Play button 122, Stop button 124, Skip Forward button 126, Scroll Up button 128 and Scroll Down button 130. However, as discussed below, these buttons (or any type of controls used with the device) can include alternate functionality that is invoked in different ways.

[0090] The device uses visual cues, or indicators, in the display. When an item is highlighted it indicates that the item is the current item, or currently-selected item, which is susceptible to be operated on by a subsequent user actionsuch as playback, or expansion of the item. In FIG. 1, screen 102 shows that the item, ALBUMS, is highlighted. The highlighted item can be acted upon by using the soft buttons, or another button, as discussed below. The current item can be changed by using Scroll Up button 128 and Scroll Down button 130 to move the highlight up or down, respectively, throughout a list of displayed items.

[0091] Icons are used to provide additional visual cues for an item. In FIG. 1, each of the categories has a category icon to the left of it. The category icon, which may not be distinctly visible in the Figure, illustrates a first box connected by lines to additional boxes below the first box. The icon depicts a hierarchy and illustrates the property of categories, i.e., that categories can contain additional categories, songs or other items.

[0092] FIG. 10 illustrates a sequence of display screens describing how to navigate to lower levels.

[0093] In FIG. 10, library category screen 150 shows the display as it appears when the user depresses library button 116 of FIG. 9. A preferred embodiment of the device uses 4 first-level categories. These are Albums, Artists, Styles and Play Lists. Each of these categories can contain, or be associated with, other categories, songs, or items.

[0094] Note that in library category screen 150 ALBUMS is currently highlighted. By depressing soft button 112 of FIG. 9, the open command is performed on the highlighted category, as indicated by the labeling of soft button 112 and soft button function description area 152 of FIG. 10.

[0095] Lists screen 154 is displayed as a result of a user opening the Albums category of library category screen 150. Lists screen 154 shows items within the Albums category such as commercial albums of multiple songs from a record label, pre-made lists or collections created by a user, or other predefined lists or collections of songs or recordings.

[0096] In FIG. 10, lists screen 154 shows each item as a list of songs. This is shown visually by the icon to the left of each item which depicts a miniature list. Possible soft button commands are Close, Open and Queue. These commands correspond to soft buttons 110, 112 and 114, respectively. If the user selects the Close command, the display reverts to library category screen 150. If the user selects the Open command, the display shows tracks screen 156. Alternatively, the user can select the Queue command to instruct the device to place all the songs from the selected (i.e., highlighted) list into the play list for eventual playback. Yet another option allows the user to press play button 122 of FIG. 9 to cause any currently-selected songs or a list of songs (e.g., an album) to immediately be played.

[0097] Returning to FIG. 10, tracks screen 156 shows that a single song called JukeBox Demo is in the list. The list is also called JukeBox Demo as shown in lists screen 154. Tracks screen 156 shows possible soft commands assigned to buttons, namely Close, Details and Queue. The Close button performs the same function as beforeit returns the user to the previous screen which, in this case, is lists screen 154. The user can also select the Details command to cause details of the song JukeBox Demo to be displayed in details screen 158 as shown in FIG. 10. The user can select the Queue command by soft button 114 to enter the selected song into the play list queue. As before, the user can also depress play button 122 of FIG. 9 to cause immediate playback of the selected song.

[0098] Details screen 158 shows information about the selected song including the name of the song, album (or list) name containing the song; the track number, if applicable, and track duration. Note that other information can be included. The user can preview the song, close the Details screen to return to the Tracks screen or queue the song on the play list queue.

[0099] The device provides the ability to preview audio files even while a current song, or playlist, is being played. When a user chooses to preview an audio file, the audio file is played for about 10 seconds while any currently-played file or playlist is suspended. After previewing is complete, the suspended file or playlist resumes playback. In other embodiment, the preview duration can vary, or be stopped by user selection.

[0100] FIG. 11 illustrates associations among items.

[0101] In FIG. 11, song 168 is one of many songs stored in the device. Categories such as albums 160, artists 162, play lists 164 and genres 166 each include sub-categories. For example, albums 160 includes the names of various albums. Songs are associated with albums, genres and playlists. Such association can be by using pointers, a data structure including items to be associated, etc. Association as used herein, includes a first item associated with a second item; and the second item associated with the first item. In other words, albums can be associated with one or more songs in the database of the device so that an automated search to find all songs associated with an album is easier. The direction of arrow pointers in FIG. 11 is not intended to limit the manner of associations among items in the present invention.

[0102] Similar to albums, the category of artists 162 includes names of artists, or performers, of songs. Each artist name is associated with one or more songs in the database. Playlists 164 includes names of playlists. These are collections of songs that can be defined by the user, the device manufacturer, or others. Each playlist can be associated with one or more songs. Genres 166 includes various styles of music which are associated with one or more songs in the database. Note that items can exist without being associated with a song. Also, items can be associated with other items as where an artist name is associated with the albums containing the songs that the artist has created.

[0103] Although not shown in FIG. 11, items can have additional information, such as properties, details, etc., associated with the item. For example, a song can have information such as play time, artist name, artist album, copyright owner, etc., associated with the song.

[0104] FIG. 12 illustrates display screens used to search for a song or other item.

[0105] In FIG. 12, screen 180 is the initial library screen, as discussed above. If the user invokes the Search command (via the appropriate soft button) with Albums selected then screen 182 is displayed. Note that the search function can be applied to any of the categories. The user can depress the Plus or Minus soft buttons to cycle through the alphabet and change the character in the current location as indicated by the cursor. The cursor position is changed by using the scroll up/scroll down buttons 128 and 130, respectively, of FIG. 9. As each letter is entered the letters are compared and the nearest match of the stored albums' names is displayed as shown in screen 184. When the desired match is displayed the user selects the Go! command.

[0106] Screen 186 shows the result of selecting the Go! command. A list of albums is displayed with the matched album centered and selected. The user can close, open or queue the album as discussed above.

[0107] FIG. 13 illustrates details of different items.

[0108] In FIG. 13, screen 200 illustrates details displayed as a result of selecting the Details command from soft button 1A track is selected. Screen 200 shows that details of the track Jukebox Demo shows the name of the album that the track resides on, the creator, or copyright owner, of the track, and the playing time of the track.

[0109] Screen 202 illustrates details of an item on the active queue list. Items are placed onto the active queue list by selecting the Queue command when an album, song, track, or other item is selected, as discussed above. For example, screen 204 shows the active queuelist where the track Jukebox Demo is selected. By invoking the Details command screen 202 is brought up to show details of the Jukebox Demo track.

[0110] As shown in screen 202, the Detail screen shows what track number the selected track is, which album the track is from; the creator, or copyright owner, of the track, and the title of the track. Additionally, the details for an item on the queue list also show playback settings. These are shown by two-letter abbreviations at the bottom of the screen. The settings are as show in Table I, below.

TABLE-US-00007 TABLE I EA Environmental Preset EQ Parametric EQ HS Headphone Spatialization TS Time Scaling 4S Four Channel Speaker Sound (only if speakers are connected)

[0111] These settings have their common meanings, as is known in the art. Note that the setting 4S is not shown in screen 202 as it is not currently active.

[0112] FIG. 14 illustrates the Nomad Jukebox coupled to a host computer system.

[0113] In FIG. 14, device 300 (e.g., the Nomad Jukebox) is coupled to host system 302. In a preferred embodiment host system 302 is a personal computer, such as an IBM-PC compatible computer. Host system 302 includes a user interface having display 304 and user input devices such as keyboard 306 and mouse 308. In other embodiments the host system need not be a full computer system. Any type of processing system having a user interface is possible. For example, it is possible to couple the device to a laptop computer, game console, web-enabled television, or any consumer electronic device or digital platform, in general. The host user interface need not provide a display and can be much more minimal than the keyboard and mouse shown in FIG. 14. A preferred embodiment of the invention uses a Universal Synchronous Bus (USB) connection but any type of connection such as IEEE 1394 (FireWire), Ethernet, Serial Port, etc. can be used. A wireless (i.e., optical or radio frequency) connection can be used.

[0114] Once device 300 is coupled to host system 302, a user of host system 302 can launch a bridge interface to allow for the transfer of files between device 300 and host system 302. In a preferred embodiment, once the bridge interface is launched, the controls of device 300 are inoperable. The user interface of host system 302 is used to operate the bridge interface to transfer files.

[0115] The invention has now been described with reference to the preferred embodiments. Alternatives and substitutions will now be apparent to persons of skill in the art.