1. Field
This disclosure relates to digital music devices, more particularly to methods for managing play lists in those music devices.
2. Background
With the advent of digital music devices, such as MP3 (Moving Pictures Experts Group, Audio Layer 3) players, users now have many configuration features available to them. Digital music players produce music from digital files stored in a memory on the player. The digital files are generally downloaded to the player from a host computer or network while the player is in communication with the host. The player may be portable, a home music system or mounted in a vehicle, as examples.
Many manufacturers of these types of players have made management of the music on the devices more user-friendly. Since the player has to be connected to a host computer or network, many of the players rely upon the intelligence of the host to configure their player. Configuration choices, such as selection of music to be loaded onto the player, as well as various means for organizing the music, are now available to these users through the host.
Play lists allow users to organize their music into ‘themed’ lists, such as by artist, year or type of music. Typically, users build a play list by manually selecting the appropriate files from their music selection. In some instances, users can sort their music files by a certain attribute. This may allow the selection of the files more convenient. The play lists are typically created on the host and the files are then downloaded into the player.
Some larger players, such as those in the home or in a vehicle, may have the capability to allow the user to create play lists on the player. Once the user has selected the files for a certain play list, the play list is saved. The user can then select this play list in the future.
When the player executes a play list, it plays all of the song in the list residing on the player. If new music is added to the player, the user must manually update the play list to include the new files. If the user does not remember the criteria used to create the play list, the user may have to recreate the list manually. Both of these processes are inconvenient, and even more so if the user has to reconnect to the host computer or network to perform these tasks.
It would be useful to allow users to perform these types of functions on the player and to store the play list criteria in such a manner as to automatically update them.
One aspect of the disclosure is a method for automatically creating a play list from search criteria. A user inputs at least one search parameter for a store of music files. The player then builds a search query from the search parameter and any other search parameters entered. The query is stored in such a manner that the query is associated with a particular play list name. When the user desires to play that play list, the entry of the play list name causes the query to be executed and a list of objects is obtained. The list of objects may in turn contain other queries, which are then executed as well. The end result is a list of music files to be played.
The invention may be best understood by reading the disclosure with reference to the drawings, wherein:
The player 10 has a panel upon which is a user interface, shown here as comprising a display 12, control buttons 14, 16 and 18 and possibly having an alphanumeric keypad 20. The control buttons may be of many different types, including push buttons, radio dials or sliders, although push buttons are shown here. The control buttons allow the user to control the playing of the music as well as to respond to items on the display 12.
The player typically has some sort of processor 26 that manages the user interface, accesses the music files and performs the necessary conversion to turn the digital information stored in the file into audio signals. Players also typically either have speakers or a headphone jack, not shown here. The processor accesses the files from the memory 22. In one embodiment of the invention, the files are organized into a database 24, which may reside in a separate memory or may be a portion of the same memory that stores the music files. For purposes of this discussion, and greater ease in understanding the invention, the database will be referred to here as a separate entity from the memory in which the music files are stored.
The database 24 generally comprises a list of the names of the music files and at least one field that defines an attribute of those files. For example, the database may have a list of files and the recorded year. The database can be searched by either the name or the year. The example of recorded year is merely intended to be illustrative. Many other attributes may be used, including multiple attributes per file.
The database of music files also provides the capability for the user to define and save play lists in a more automated fashion. Currently, users typically have to specify each file that is to be added to a play list. For example, Creative Labs™ has a product it includes with some of its digital music players, referred to as a ‘jukebox.’ Similarly, RealNetworks™ has a product that can be downloaded from their web site titled ‘RealJukebox™.’ These products allow users to organize their music files into play lists for easy access later, but very little automation is provided for organizing these play lists.
For example, a user wants to create a play list. In some instances, the user must access the jukebox view on a PC or other host. The user selects from a series of pull-down menus and option buttons. A typically process would be as follows. The user selects “Create Play List” from a list of options and then is prompted to provide a name for the play list. The user then goes through the entire music collection available that the jukebox application has been able to locate on the host and manually selects the files to be added to the new play list. Once finished, the user then selects an option such as ‘Add to Play List.’ The play list is then created from those files.
If the user wants to add other tracks to the play list, the user has to manually sort through the music collection again and select files to be added. If new music has been added to the PC or the player, the user may have to manually compare the current play list to the possible files to determine if the play list is up to date with the new music on the PC or player. This is inconvenient and time consuming.
Using the player of
In
If the user wishes to refine the search further, the user may make a selection that is joined with the current search parameter by one of any number of operators. In the example of
As can be seen in
It must be noted that the next stages of identifying the files using the query at 46 and the play list created from the files at 46 in
One advantage of this approach is the ability for the player to dynamically update the play list as new music is added to the player. As discussed previously, the addition of new music would require the user to go through the new music and determine to which play lists the new files would need to be added to update those play lists. In the embodiment of the invention discussed above, there is no inflexible list of files that are designated as the play list. If the query is run, and the new files meet the criteria in the query, the files will be part of the play list.
This is shown in
The query itself may be a combination of queries. For example, the user may set up play list 1 with the specifications of artist A and year 2000. Play list 2 may have the files corresponding to music by artist B. Through the user interface, the user may create play list 3 as being play list 1 and play list 2. The player would interpret play list one as being Play list 3 would be stored in some manner that would combine the two queries, such as <<Artist=“A”:AND:year=2000>+<Artist=“B”>>. The player would ‘flatten’ the queries and provide a list of files. It should be noted that this last operation will more than likely be two operations, as to state Artist=A and Artist=B would be mutually exclusive. The operations will more than likely be concatenated, indicated above with the “+” sign.
Because of the ability to have multi-level queries, the list of objects may not be a list of files for immediate playing. Instead the list of objects provided at 56 may comprise an intermediate step. When the individual objects are all flattened or converted into the list of music files, the list of files would be provided at 58. Again, this may be an optional and unnecessary step, if no multi-level queries are stored as play lists. More detail can be found on multi-level, or hierarchical, play lists in copending U.S. patent application Ser. No. 09/595,818, filed Jul. 16, 2000, entitled “Digital Music Systems”, incorporated by reference herein.
In this manner, the users are provided an automated method to identify files for particular play lists. The method allows for dynamic updating of the specified files in a particular play list, transparent to the user. It also allows the storage of the play lists in terms of a query rather than an entire list of files.
Thus, although there has been described to this point a particular embodiment for a method and apparatus for automatically generating play lists from search criteria in music players, it is not intended that such specific references be considered as limitations upon the scope of this invention except in-so-far as set forth in the following claims.
Number | Name | Date | Kind |
---|---|---|---|
5265248 | Moulios et al. | Nov 1993 | A |
5454106 | Burns et al. | Sep 1995 | A |
5630005 | Ort et al. | May 1997 | A |
5751672 | Yankowski | May 1998 | A |
5808224 | Kato | Sep 1998 | A |
5947746 | Tsai | Sep 1999 | A |
5969283 | Looney et al. | Oct 1999 | A |
5987525 | Roberts et al. | Nov 1999 | A |
6038199 | Pawlowski et al. | Mar 2000 | A |
6225546 | Kraft et al. | May 2001 | B1 |
6248946 | Dwek | Jun 2001 | B1 |
6252830 | Hsu | Jun 2001 | B1 |
6278048 | Lee | Aug 2001 | B1 |
6289165 | Abecassis | Sep 2001 | B1 |
6324537 | Moran | Nov 2001 | B1 |
6349797 | Newville et al. | Feb 2002 | B1 |
6389467 | Eyal | May 2002 | B1 |
6423892 | Ramaswamy | Jul 2002 | B1 |
6446080 | Van Ryzin et al. | Sep 2002 | B1 |
6452609 | Katinsky et al. | Sep 2002 | B1 |
6484156 | Gupta et al. | Nov 2002 | B1 |
6496802 | van Zoest et al. | Dec 2002 | B1 |
6505160 | Levy et al. | Jan 2003 | B1 |
6519648 | Eyal | Feb 2003 | B1 |
6526411 | Ward | Feb 2003 | B1 |
6587835 | Treyz et al. | Jul 2003 | B1 |
6590303 | Austin et al. | Jul 2003 | B1 |
6662231 | Drosset et al. | Dec 2003 | B1 |
6670934 | Muoio et al. | Dec 2003 | B1 |
6693236 | Gould et al. | Feb 2004 | B1 |
6701355 | Brandt et al. | Mar 2004 | B1 |
6718308 | Nolting | Apr 2004 | B1 |
6771568 | Hochendoner | Aug 2004 | B1 |
6850252 | Hoffberg | Feb 2005 | B1 |
6965770 | Walsh et al. | Nov 2005 | B1 |
6996390 | Herley et al. | Feb 2006 | B1 |
20020002039 | Qureshey et al. | Jan 2002 | A1 |
20020045960 | Phillips et al. | Apr 2002 | A1 |
20020055934 | Lipscomb et al. | May 2002 | A1 |
20020069218 | Sull et al. | Jun 2002 | A1 |
20020151327 | Levitt | Oct 2002 | A1 |
20020152876 | Hughes et al. | Oct 2002 | A1 |
20020171567 | Altare et al. | Nov 2002 | A1 |
20030050058 | Walsh et al. | Mar 2003 | A1 |
20030236711 | Deguchi | Dec 2003 | A1 |
20040002310 | Herley et al. | Jan 2004 | A1 |
20050108413 | Melmon | May 2005 | A1 |
20050262528 | Herley et al. | Nov 2005 | A1 |
20060004948 | Grace et al. | Jan 2006 | A1 |
20060008256 | Khedouri et al. | Jan 2006 | A1 |
20060112144 | Ireton | May 2006 | A1 |
Number | Date | Country | |
---|---|---|---|
20030065639 A1 | Apr 2003 | US |