(12) United States Patent
`Goodman et al.
`
`(10) Patent N0.:
`(45) Date of Patent:
`
`US 6,928,433 B2
`Aug. 9, 2005
`
`US006928433B2
`
`(54) AUTOMATIC HIERARCHICAL
`CATEGORIZATION OF MUSIC BY
`METADATA
`
`(75)
`
`Inventors: Ron Goodman, Santa Cruz, CA (US);
`Howard N, Egan, Capjtola, CA (US)
`
`(73) Assignee: Creative Technology LTD, Singapore
`(SG)
`
`( * ) N0tiCeI
`
`Sllbjeet t0 any disclaimer, the term Of thiS
`patent is extended or adjusted under 35
`U-S-C 154(b) by 323 days.
`
`(21) Appl, No; 09/755,723
`.
`Ffledi
`
`(22)
`(65)
`
`Jan‘ 59 2001
`prim. publication Data
`US 2002/0147728 A1 Oct. 10, 2002
`
`Int. Cl.7 .............................................. .. G06F 17/30
`(51)
`.
`.
`.
`............................. ..
`'
`'
`/
`'
`(52) U S C]
`707/4’ 707/3’ 7037332126’
`(58) Field of Search ........................ .. 84/609, 601, 602,
`84/611-614; 707/104.1, 3, 4, 102, 386/46
`
`(56)
`
`References Cited
`
`U-S- PATENT DOCUMENTS
`5,616,876 A *
`4/1997 Cluts ......................... .. 84/609
`
`. . . .
`. . . . N 84/609
`5,670,730 A 4
`9/1997 Grcwc ct a1.
`5,918,303 A 4
`6/1999 Yamaura et a1.
`.
`84/609
`.............. .. 84/609
`5,969,283 A * 10/1999 Looney et al.
`6,062,868 A *
`5/2000 Toriumi ................ .. 434/307 A
`
`6/2001 Dwek ........................ .. 84/609
`6,248,946 B1 *
`4/2002 Burrows
`6,377,530 B1
`1/2003 Robbins .................... .. 386/46
`2003/0016940 A1 *
`OTHER PUBLICATIONS
`
`Web page, Menta, Richard, “1200 Song MP3 Portable is a
`Milestone Player,” MP3 iieWsWire.iiet, Jan. 11, 2000, 5
`pages, http://pjbox.com/newswire/.
`Web page on “MusicMatch Jukebox 4.0: Screen Shot 1,” PC
`Magazine, Jun. 17, 1999, 2 pages, http://Web.archiVe.org/
`Web20000226113655/WWW.zdnet.com/products/stories/re-
`views/0,4161,2277814,00,htm1,
`Web page, Norton, Patrick, “MusicMatch Jukebox 4.1, the
`Ultimate MP3 Utility,” techtv, Sep. 17, 1999, 2 pages,
`http://WvvW.techtv.com/freshgear/print/0,23102,2324631,
`00.html.
`Web page on “Can you carry your CD collection in your
`pocket? Yes, you can.” Compaq Web site, 3 pages, http://
`research.compaq.com/SRC/pjb/, Printed on Apr. 30, 2004.
`.
`.
`* cited by examiner
`P ,
`E
`,
`_Ch 1 R
`nmary mmmer
`ar es Ones
`(74) Attorney, Agent, or Firm—Russell N. Swerdon;
`Creative T"°h“°1°gy LTD
`(57)
`ABSTRACT
`
`A method, performedby software executing on the proces-
`sor of a portable music playback device, that automatically
`files tracks according to hierarchical structure of categories
`‘°,9rga“1Z‘°' ‘racks 1“ a 1F’g1"a1 0rd?“ A “Set Interface 15
`utilized to change the hierarchy, view track names, and
`select tracks for playback or other operations.
`
`16 Claims, 12 Drawing Sheets
`
`Oasis Play - My Configuaration
`Playlists
`
`IEIEJE
`
`Meddle/Pink Floyd
`One of these days Pink Floyd Meddle
`A Pillow of W...
`Pink Floyd Meddle
`Fearless
`Pink Floyd Meddle
`San Tropez
`Pink Floyd Meddle
`Pink Floyd Meddle
`Pink Floyd Meddle
`
`Slow
`Med
`Slow
`Fast
`Slow
`Slow
`
`‘
`
`'
`'
`
`_
`I The Wall/Pink Floyd
`
`A" Playlists
`
`New P'aV"st"'
`
`C0nVe|'t F°Tmat---
`
`Copy To Clipboard
`
`Cut To Clipboard
`
`Paste from Clipboard
`
`{I
`
`SONY Exhibit 1001
`
`SONY Exhibit 1001
`SONY v. Creative
`
`SONY V. Creative
`
`

`
`U.S. Patent
`
`Aug. 9,2005
`
`Sheet 1 of 12
`
`US 6,928,433 B2
`
`Root
`
`Cate or
`. 9
`
`Y
`
`C t
`. 3990W
`
`C t
`. 3:900!
`
`Value
`1
`
`Value
`2
`
`0 0 0 0 0 0 6tracks
`
`0 0 0
`3 tracks
`
`0 0 0
`3 tracks
`
`Q
`
`Subcategory
`Value 1
`
`Q
`
`Subcategory
`Value 2
`
`Category
`Category
`Category
`Category
`. Value . Value . Value . Value
`1
`2
`3
`4
`
`O O
`2 tracks
`
`O O
`2 tracks
`
`O
`1 track
`
`O
`1 track
`
`For example:
`Category 1 = Album Name
`Category Value 1 = Abbey Road
`Category Value 2 = Hits from the 60's
`
`Category 2 = Artist Name
`Subcategory Value 1 = British Artists
`Subcategory Value 2 = American Artists
`Category Value 1 = The Beatles
`Category Value 2 = Petula Clark
`Category Value 3 = Mamas and the Papas
`Category Value 4 = Nick Drake
`
`Category 3 = All tracks
`
`FIG. 1.
`
`

`
`U.S. Patent
`
`Aug. 9,2005
`
`Sheet 2 of 12
`
`US 6,928,433 B2
`
`V1.0
`
`A|bums|OxO1|BLBN
`Artists|0xO1|BCBMBN
`All Tracks|OxO1|BN
`
`FIG. 2.
`
`Album Name
`
`Abbey Road
`Golden Slumbers
`
`Something
`
`Sun King
`Hits of the 60's
`
`Cheatin Heart
`
`Monday, Monday
`Fruit Tree
`
`Artist Name
`
`British Artists
`
`Beatles
`
`Golden Slumbers
`
`Something
`
`Sun King
`
`Petula Clark
`
`Cheatin Heart
`
`Mamas and the Papas
`Monday, Monday
`Nick Drake
`
`Fruit Tree
`
`All tracks
`
`Golden Slumbers
`
`Something
`Sun King
`Cheatin Heart
`
`Monday, Monday
`Fruit Tree
`
`FIG. 3.
`
`

`
`U.S. Patent
`
`Aug. 9,2005
`
`Sheet 3 of 12
`
`US 6,928,433 B2
`
`|:|— — —I- — - Content
`:—— — — Play List
`EU——.—
`
`I I
`
`--—--By Name
`
`I I
`
`- — - — -By Source
`
`I 1
`
`- — — — —By Genre
`
`I I I I I I I
`
`- —
`
`— Rock
`
`HIE- II I I
`
`— —l — Jazz
`
`%-- - - -By Name
`
`'——— — -ByA|bum
`
`FIG. 4.
`
`FIG. 5.
`
`

`
`U.S. Patent
`
`Aug. 9,2005
`
`Sheet 4 of 12
`
`US 6,928,433 B2
`
`HDREACH
`
`TRACK
`
`
`
`HDREACH
`
`BRANCH
`
`
`NEXT
`
`BRANCH
`
`
`IS THIS
`THE RIGHT KIND OF
`
`
`RACK FOR THIS BRANCH (E.G.,
`MUSIC, VOICE,
`
`VIDEO?)
`
`TRAVERSEBRANCHAND
`
`
`
`
`
`
`
`
`LOCAWONFORTHB
`
`TRACK
`
`HNDTHEAPPROPRMTE
`
`
`
`FIG. 6.
`
`

`
`U.S. Patent
`
`Aug. 9,2005
`
`Sheet 5 of 12
`
`US 6,928,433 B2
`
`%
`
`.c_mn_moi
`
`v:m_moEo
`
`t.®n_Eo._.II
`
`

`
`U.S. Patent
`
`Aug. 9,2005
`
`Sheet 6 of 12
`
`US 6,928,433 B2
`
`
`
`.....mE_ou_tw>coo
`
`Emon_Q__ooh300
`
`E_8%___oohso
`
`
`
`Eaona__oE9:Emma.
`
`%
`
`sew
`
`82
`
`>>O_W
`
`mm;
`
`;o_m
`
`;o_m
`
`w=o_um_>_
`
`m__oUm_>_
`
`m_UUm_>_
`
`m_U_umS_
`
`m_U_uo_>_
`
`m_U_um_2
`
`
`
`...m__>m_n_262
`
`
`
`mm__>m_n_
`
`
`
`U>O_n_xc_&o__o_8s_HI
`
`
`
`
`
`:o_..m.m:m_Eoo>_>_->m_n_m_mmO
`
`E E
`
`fig
`
`
`
`
`
`xc_n_w>m_ummmfiBmco96.“.xc_n_...>>.6>>o___n_<v>o_u_
`
`
`
`
`
`
`
`
`
`u>o_n_x:_n_mmm:mou_
`
`
`
`
`
`u>o_u_xc_n_~80:cam
`
`Ear.EaSm
`
`_26_n_Eammofim
`
`
`
`E2“.v_:_n_\__m>>9:I
`
`
`
`2m__>m_n___<E
`
`
`
`mmcom__<I
`
`
`
`

`
`U.S. Patent
`
`Aug. 9,2005
`
`Sheet 7 of 12
`
`US 6,928,433 B2
`
`FIG. 9
`
`

`
`U.S. Patent
`
`Aug. 9,2005
`
`Sheet 8 of 12
`
`US 6,928,433 B2
`
`3
`
`GE3
`
`Seemm__Soo
`
`
`
`65.3..coucmqxo865.8
`
`Em5_._cans.on.3$5.E889:.
`
`
`I-zqua§..J_
`
`----o.s_m.mxommxa.
`
`me
`
`dmeomw__mEn_m599mm_>m:9w.__<._.mn_amen.
`
`
`
`"......--osmq§m9§fi
`
`
`
`:$.5m9.09....
`
`
`
`osmaxommxaHm:
`
`E
`
`
`
`mmmzmzmmO._.._.I0_z<m.
`
`
`
`Emzaw>_._._wOn_M
`
`
`
`
`
`msmsozmaommo._o
`
`
`
`:$..um3m_._
`
`
`
`
`
`_.:$bmflow.»m52amass:9zmaoamen>.rm.m<w_..w.w_._.ra._.m<xoomE_-....:0was
`
`
`
`
`
`....=2:.eE
`
`_W..
`
`
`
`
`
`9:22%_>22E225zomvzmn_ommmi.bm5_._o_m:s_9.:we_m>o_ason»
`
`
`cooammo_._om2mo
`...............-.m5_E<m.-
`_,..............--w§mz..fi.
`
`
`
`
`
`.:m.m.omma:
`
`
`
`xomfiwzmao
`
`L_.m:><.Ean
`
`mmztme.
`
`Ce
`
`
`
`
`
`
`

`
`U.S. Patent
`
`Aug. 9,2005
`
`Sheet 9 of 12
`
`US 6,928,433 B2
`
`3.0_u_
`
`mmztm
`
`awmzmov
`
`2
`
`Q
`
`
`
`Eb:><._n._
`
`m5_E<
`
`ms5m:<
`
`=Emu»
`
`cmmacoo
`
`SE.65E<
`
`£w§§<2.:E
`
`mmcmm£Eo.¢mmcom
`
`
`
`
`

`
`U.S. Patent
`
`g
`
`US 6,928,433 B2
`
`
`
`MI.,|llmE=£<._8I’:l|;o.mom.
`
`
`
`
`
`M..mEu28_u_5cozaoaEcosaw.me
`
`mmcmzo2w:z_s=w:._n_mmmi.m...........................<._.z_z<m,was222.3zaooaajomomweamsmmoHo<9.mmma55Em.26.oz...._.mas.
`
`
`
`
`
`$2.2man.60
`
`N2.
`
`......................<aam236.ms.353m_EEsomem<M52mmmmE=n_<.2suaom
`D.$2.2ms:..00X:M.§m_%_um_some_$§awe£519$n_OEmaw_2Dm._<9:.2ms5m._<9:ES,8.858
`
`
`
`
`
`
`
`m_..07.
`
`
`
`
`E332:.gemsfiemmc_.-........-.fiu<.m.mo._.,w.m..m.m..
`
`
`E2E22somama4.ozaoz_.m_mm<mmM$5n_<oz_m<0z_omzz<mM
`
`
`.82805co9.82;.----2.mB©.:.Em_m.u_o.._.mmm.m._
`
`
`
`msmsczmmommod02
`
`mumto5mmm
`
`Iomfimzmao.1
`
`._.m_._><._n_4wm._>._.me.
`
`
`
`.:m2owm_>_:m:<mo“.zomfim2:mwmoom9.zomfimmw2n_.~
`
`
`
`
`
`.ws53<60.39223zaoens._._omom$054
`
`
`_,..............--w2am..z...u
`...............{w._.w_.E<...m-
`
`
`
`
`
`

`
`U.S. Patent
`
`UA
`
`9:g
`
`US 6,928,433 B2
`
`xomw:w>xHN58%$.05:9:9E292wwodmmwiN
`com.mfiooa.M..ozmo
`
`
`
`massmmod>>m_>mmn_
`
`
`
`
`
`mmE86»hm:msmaom>:.o<msE8Bmmmuowflimom=.§m.S
`
`
`
`
`
`
`
`
`
`
`w.__<._.moash._.—w_._m_..m:om>:.o<r..3.%g_.S.252in9.5%.$3_........--------%28$.>m__nm__u:mmS_,o_mn28mwmvmnmcfiwmxo2>w_n_o_u:<53>aemms| .--wm¢wmA_M§m.“m...wmw~mwuan-Aw...c<_.LV3:asmm_we598Sana2:.E32...
`
`
`
`
`zow._...._zV529H§<_,eW__,,\_§,m,§.w
`
`
`
`«om>.E<n_zweéo-
`
`3GE
`
`New
`
`woos.
`
`
`
`
`
`dmmbm5:mamzom>_._.o<9:2E329xoémmmi.N
`
`
`
`
`
`8...—".9xo<En><._n_
`
`
`
`osmaxomm::_.
`
`
`
`osmaxom_mv_2.
`
`.oz_.N>x
`
`
`
`
`
`m:.m<m:om$<._._oom.__<mo
`
`
`
`
`
`
`
`.e_5_<.890v_om.._.9:%_%_ucmeomw.__<._.wn_2:.m.=<._.mo.m$._n_.—
`
`fie.2,38:23Em55osmaxommxaum:
`
`u......-.oEE~.o.mm.m.g....m.n
`
`
`
`
`
`
`
`58%865:weSEnwamoa23%is
`
`
`
`
`
`

`
`U.S. Patent
`
`Aug. 9,2005
`
`Sheet 12 of 12
`
`US 6,928,433 B2
`
`HOST
`
`302
`
`304
`
`300
`
`
`
`308
`
`306
`
`FIG. 14
`
`

`
`US 6,928,433 B2
`
`1
`AUTOMATIC HIERARCHICAL
`CATEGORIZATION OF MUSIC BY
`METADATA
`
`CROSS-REFERENCES TO RELATED
`APPLICATIONS
`
`This application is related to Application Ser. No. 09/755 ,
`629, entitled “System for Selecting and Playing Songs in a
`Playback Device with a Limited User Interface,” now aban-
`doned and Application Ser. No. 09/755,367, entitled
`“Audioplayback Device with Power Savings Storage Access
`Mode,” issued as U.S. Pat. No. 6,590,730, all filed Jan. 5,
`2001, the disclosures of which are incorporated herein by
`reference.
`
`BACKGROUND OF THE INVENTION
`
`Today, portable consumer electronic devices are more
`powerful
`than ever. For example, small, portable music
`playback devices can store hundreds, even thousands, of
`compressed songs and can play back the songs at high
`quality. With the capacity for so many songs, a playback
`device can store many songs from different albums, artists,
`styles of music, etc.
`Music jukeboxes implemented in software executed by a
`digital computer and portable MP3 and CD players both
`provide facilities for forming playlists. For example,
`the
`OOZIC player, distributed by the assignee of the present
`application, runs on a host PC and has a playlist feature that
`allows selection of tracks from the PC’s hard disk to be
`
`included in the playlist.
`As storage capacity increases and songs are compressed
`to shorter file lengths the number of songs that can be stored
`increases rapidly. Major problems facing the consumer are
`organizing and accessing the tracks.
`Typically, portable devices have a user interface including
`a small screen and buttons. Such a display screen might be,
`e.g., 1“><2“. This small display size is necessary because of
`the physical size of the device which is typically carried in
`the hand. The small size also limits the number, size, shape,
`and types of user input controls that can be mounted on the
`device. For example, a few pushbuttons are usually provided
`to perform all of the device’s control functions. Using such
`a compact user interface to navigate and select among
`hundreds of songs is inefficient and often frustrating. The
`display screen can only show a few song titles at one time,
`and the limited controls make it difficult for a user to
`
`arbitrarily select, or move among, the songs.
`The creation of playlists is one technique to organize the
`playing of songs. A set of songs can be included in a playlist
`which is given a name and stored. When the playlist is
`accessed, the set of songs can be played utilizing various
`formats such as sequential play or shuffle.
`However, the creation of playlists itself becomes prob-
`lematic as the number of songs increases, since the user
`often arbitrarily selects songs from a large number of tracks
`to form a playlist. This selection mechanism: can be fairly
`tedious; does not necessarily produce playlists that are of
`interest to the user over the course of time; may not remain
`up-to-date if new songs are added that logically fit into a
`previously created playlist (e.g. “Favorites by Band X”
`might become out of date if a new favorite by Band X is
`added after the playlist was created); and leads to “lost”
`songs that are not members of any playlist.
`Accordingly,
`improved techniques for organizing and
`grouping tracks useful in a portable music player are needed.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`Further, it is desirable to provide a user interface suitable for
`a small device. The user interface should allow a user to
`efficiently navigate among, and select from, many items
`stored in the device.
`
`SUMMARY OF THE INVENTION
`The present invention provides an efficient user interface for
`a small portable music player. The invention is suitable for
`use with a limited display area and small number of controls
`to allow a user to efficiently and intuitively navigate among,
`and select, songs to be played. By using the invention, very
`large numbers of songs can be easily accessed and played.
`One aspect of the invention includes an overlapping
`hierarchy of categories. Categories include items that can
`also be included in other categories so that the categories
`“overlap” with each other. Thus, a song title can be accessed
`in multiple different ways by starting with different catego-
`ries. For example, 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. Similarly,
`the Artists category includes
`names of artists which are, in turn, associated with their
`albums and songs. The Genre category includes types of
`categories of music such as “Rock”, “Hip Hop”, “Rap”,
`“Easy Listening”, etc. Within these sub-categories are found
`associated songs. Finally, the “Play Lists” category includes
`collections of albums and/or songs which are typically
`defined by the user.
`Advantageous use is made of the overlapping hierarchy to
`allow the user to quickly designate a song for playback. The
`device uses three “soft” pushbuttons that have assignable
`functions. The interface maintains consistent button func-
`
`tionality whenever possible and uses uniform command
`names and operations in different types of items so that the
`interface is more intuitive. For example, the user can open
`and queue both albums and songs with predictable results.
`The interface also provides for multiple functions for a
`single control. For example, a “Play” button can act, in a first
`function, to play a currently-selected song. The Play button
`can act, in a second function,
`to cycle through different
`playback modes. The modes can be, e.g., (1) playback of
`songs from a hard disk; (2) playback of music from a radio
`receiver built into the device; and (3) playback of voice
`messages. The first function for the Play button can be
`activated by momentarily depressing the Play button for a
`short period of time. The second function is invoked by
`depressing the Play button for a longer period of time
`whereupon the device cycles through the different modes.
`Other ways of invoking the functions are possible such as
`where the second function is automatically entered from a
`powered-down state.
`In one embodiment, the invention provides a method for
`selecting songs to be played in an electronic audio device,
`wherein the device includes a display and one or more user
`input controls, wherein songs are organized into categories,
`albums, wherein songs and albums are associated with artist
`names. The method includes steps of displaying categories
`on the display; accepting signals from a user input control to
`select a category; displaying one or more songs in the
`selected category on the display; accepting signals from a
`user input control to select a displayed song; and entering
`selected songs into a playlist queue, wherein the device
`plays back songs in the playlist queue.
`invention, a
`According to one aspect of the present
`technique is provided for organizing tracks on a portable
`music player by automatically filing tracks in a hierarchical
`order based on attributes of the tracks.
`
`

`
`US 6,928,433 B2
`
`4
`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.
`
`In the currently defined embodiment, a tree structure is
`defined by a file having the following structure.
`The first line of a TreeDef.inf file contains a version
`number:
`
`10
`
`3
`According to another aspect of the invention, metadata is
`associated with each track that is used to automatically
`define the track’s appropriate place in the hierarchy.
`According to another aspect of the invention, the hierar-
`chy is displayed on the portable music player so that a user
`can traverse the organizational hierarchy to find individual
`tracks or find playlists composed of logical groups of tracks.
`According to another aspect of the invention, the hierar-
`chy is derived by using metadata associated with the audio
`content that was obtained through any source of metadata
`(e.g. CDDB metadata,
`id3v2 metadata, other obtainable
`metadata) and subsequently stored with or alongside the file
`that stores the track.
`
`According to another aspect of the invention, a file is
`formatted so that an unaltered track is stored as file data and
`information about the track is stored in file attribute files.
`
`15
`
`Other features and advantages of the invention will be
`apparent in view of the following detailed description and
`appended drawings.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 is a schematic diagram of a tree structure for
`hierarchical filing of tracks;
`FIG. 2 is a definition file that specifies the hierarchy
`depicted in FIG. 1;
`FIG. 3 is a user’s view of the hierarchy;
`FIG. 4 is a schematic diagram of a user interface display-
`ing the hierarchical category structure;
`FIG. 5 is a diagram of a file format for storing filed data
`and file attributes;
`FIG. 6 is a flow chart depicting steps for filing tracks
`according to the hierarchical tree structure;
`FIG. 7 depicts a tree resulting from searching the tracks;
`and
`
`FIG. 8 depicts a format for a user interface;
`FIG. 9 illustrates the NOMAD Jukebox and its user
`interface controls;
`FIG. 10 illustrates a sequence of display screens describ-
`ing how to navigate to lower levels;
`FIG. 11 illustrates associations among items;
`FIG. 12 shows display screens used to search for a song
`or other item;
`FIG. 13 illustrates details of different items; and
`FIG. 14 illustrates a playback device coupled to a host
`computer system.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`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,
`wav. or other digital formats.
`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
`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
`
`20
`
`25
`
`30
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`V1.0
`
`Each subsequent line (at least in V1.0) contains lines of the
`following format:
`CATEGORY_NAME|TRACK_TYPE
`MASK|CATEGORY_STRUCTURE
`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.
`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 ‘OX’ format, e.g.
`0X01) generated by ORing the following flags together
`as appropriate:
`
`enum tTrackType
`{
`
`kTI'Nothing=0x00,
`kTTSong=0x01,
`kTI'Voice=0x02,
`kTI'Book=0x04,
`kTIMacro=0x08,
`kTI'Playlist=0x10
`
`};
`
`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).
`Other elements might be added to tTrackType (e.g.
`kTTVideo) as appropriate.
`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:
`
`enum tFileTag
`{
`
`kFTNone=‘ @ ’ ,
`kFITrackType=‘T’,
`kFITitle=‘N’,
`kFTAudioFile=‘ F’,
`kFTArtist=‘ M ’ ,
`kFTAlbum=‘ L’ ,
`kFTGenre=‘G’,
`kFTSource=‘ S’,
`kFTYear=’Y’,
`kFTArtistCountry=’C’
`
`};
`
`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.
`
`

`
`US 6,928,433 B2
`
`In total, a line like:
`Album|0><01|LN
`Says to create a branch called “Album” which contains
`tracks of type kTTSong organized first by album name, and
`then by track name.
`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 metadata—thus each group of two letters
`represents a level in the hierarchy):
`
`V1.0
`Album|0x01|BLBN
`Artist|0x01|BMBN
`Genre|0x01|BGBN
`Voice Tracks|0x02|BSBGBN
`Playlists|0x10|BN
`Macros|0x08|BN
`All Tracks|0x07|BN
`
`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.
`The tree definition file that would specify the hierarchy
`shown in FIG. 1 is shown in FIG. 2.
`The first line identifies the version of the tree definition
`file.
`The second line defines the “Albums” branch. The first
`
`part of the line, “Albums” defines the name of the branch.
`The second part, “0><01,” 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).
`The third line defines the “Artists” branch. The first part
`of the line “Artists” defines the name of the branch. The
`
`second part, “0><01, ” 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).
`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.
`
`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.
`An embodiment of the invention is utilized in the
`
`Nomad® Jukebox, manufactured by the assignee of the
`
`6
`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).
`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 cat-
`egory 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.
`Thus, the 11ser is automatically provided with a powerfill
`and flexible tool for organizing and categorizing the tracks
`stored on the portable player.
`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 alter-
`nate 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.
`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.
`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.
`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.
`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 Tracklnfo Data Field
`
`Field
`Attribute Count
`
`Offset
`0
`
`Attr 1 type
`Attr 1 name len
`Attr1 data len
`Attr1 Name
`Attr 1 Data
`
`2
`4
`6
`10
`10 + N
`
`Size Description
`2
`The number of attribute follow for
`the track
`Binary = 0, ASCII = 1
`Length of attribute name string
`Length of attribute data
`Attribute name string
`Attribute data
`
`2
`2
`4
`N
`M
`
`Attr N type
`Attr 1 name len
`Attr1 data len
`Attr1 Name
`Attr 1 Data
`
`10
`
`15
`
`20
`
`25
`
`30
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`

`
`US 6,928,433 B2
`
`-continued
`
`Required Attributes
`
`Attribute Name
`
`Value(s)
`
`Remarks
`
`TITLE
`CODEC
`TRACK ID
`ALBUM
`ARTIST
`GENRE
`LENGTH
`TRACK SIZE
`TRACK NUM
`
`ASCII string
`“MP3", “WMA”, “WAV”
`DWORD
`ASCII string
`ASCII string
`ASCII string
`In seconds
`In bytes
`1—n (track within album)
`
`RequiredByJukebox
`ReguiredByJukebox
`Set By Jukebox
`Optional
`Optional
`Optional
`Optional
`Optional
`Optional
`
`These attributes can be subsequently changeable via a
`host application, running on a personal computer connected
`to the portable music player.
`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.
`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.
`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.
`
`The following example shows the algorithm for adding a
`track. For clarity, only the attributes used by the tree are
`shown.
`
`TITLE
`ALBUM
`ARTIST
`GENRE
`TRACK NUM
`
`“Free Falling”
`“Full Moon Fever"
`“Tom Petty”
`“Rock”
`1
`
`The following function is executed to build the
`in-memory memory tree.
`
`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
`
`FIG. 7 depicts a tree which could result from implement-
`ing 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.
`
`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
`
`8
`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.
`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.
`FIG. 9 illustrates the NOMAD Jukebox and its user
`interface controls.
`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.
`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.
`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 button 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.
`IIowever, as discussed below, these buttons (or any type of
`controls used with the device) can include alternate func-
`tionality that is invoked in different ways.
`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 currenty-selected item, which is suscep-
`tible to be operated on by a subsequent user action—such as
`playback, or expansion of the item. In FIG. 1, screen 102
`shows that the item, “ALBUMS,” is highlighted. The high-
`lighted item can be acted upon by using the soft buttons, or
`another button, as decribed 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.
`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 con-
`nected 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.
`FIG. 10 illustrates a sequence of display screens describ-
`ing how to navigate to lower levels.
`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.
`Note that in library category screen 150 ALBUMS is
`currently highlighted. By depressing soft button 112 of FIG.
`
`10
`
`15
`
`20
`
`25
`
`30
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`

`
`US 6,928,433 B2
`
`9
`9, the “open” com