Exemplary embodiments of the present invention relate, generally, to creating variations of a music file and, in particular, to a technique for sharing the variations created.
In general, musical works are typically composed of a melody, harmony, dynamics and rhythm, and it is based on these characteristics that a musical work is often perceived and analyzed. Music rhythm is the organization of a musical work in relation to time. In particular, the rhythm consists of various pulse sensations occurring at different time scales or levels. The most prominent time scale or level of pulse sensations is the foot tapping rate, also referred to as the tactus or beat. As used herein, the term “beat” is used to refer to the individual elements that make up a given pulse.
The next time scale or level of pulse sensations is the bar or musical measure. In general, a bar or musical measure pulse relates to the harmonic change rate or the length of a rhythmic pattern. In music notations, these rhythmic patterns (i.e., measures or bars) are separated by bar lines. Typically, every Nth beat of the tactus pulse coincides with a beat of the measure pulse (i.e., measures can typically be divided into N beats, where N is some fixed integer value greater than one).
A fair amount of research interest has been directed towards analyzing the basic pattern of beats in a piece of music (i.e., the musical meter) and towards automatically tracking the beats of a sampled musical work. In particular, research has been performed to study the estimations of a music measure and to develop a measure or bar line estimator. See e.g., Klapuri, Anssi P, et al.: Analysis of the Meter of Acoustic Musical Signals, IEEE Transactions on Audio, Speech and Language Processing, Vol. 14, No. 1, pp. 342-355, January 2006 (referred to hereinafter as “Klapuri et al.”), the contents of which are hereby incorporated herein by reference.
Many musical pieces, especially those from the pop music category, have a distinguishable segment structure, where the different segments may repeat. Typical sections in music include, for example, the intro, verse, bridge, chorus, and outro. A typical repeating structure of a pop music file may be, for example, “intro, verse, chorus, verse, chorus, chorus.” Research has been done to detect the choruses and other repeating sections in music. See e,g,, Masataka Goto: A Chorus-Section Detecting Method for Musical Audio Signals, ICASSP 2003 (The 2003 IEEE International Conference on Acoustics, Speech, and Signal Processing) Proceedings, pp. V-437,440, April 2003. (referred to hereinafter as “Goto”), the contents of which are hereby incorporated herein by reference.
In a typical music player, a user is able to play, stop, pause, fast forward and rewind a musical work, as well as skip to a next or previous track of a musical collection. With most conventional fast forward and rewind functionalities, the user is able to move fast within the musical work or track, but because no attention is paid to the basic beat pattern of the work while doing so, the continuity and musically pleasing aspects of the musical work are often sacrificed. In addition, using a standard music player, there is typically no way to alter the length of a musical work (i.e., shorten or lengthen the musical work) absent cutting the work off prior to its completion or simply playing the musical work back again.
A need, therefore, exists, for a technique for implementing typical music player functionality (e.g., playing, pausing, fast forwarding and rewinding a musical work) in a manner that allows the musical work to remain musically pleasing, as well as provides increased functionality (e.g., enabling a user to shorten and/or lengthen the duration of the musical work).
Using a disc jockey (“DJ”) device or audio editor, a user may be able to rearrange and loop sections of a musical work in the desired manner discussed above. In particular, the user may be able to segment the musical work and thereafter rearrange the segments or sections or set a particular section to loop a predetermined amount of times. This may be possible even in real-time, such that the DJ is able to change the playback order of a music segments during a live performance. In general, however, the user interface of these devices is rather complicated for the amateur listener. For example, in order for the resulting musical work (i.e., the result of the user's segmenting, rearranging and looping) to remain continuous, the user him/herself may be required to segment the musical work according to the beats, measures or segments (e.g., intro, verse, chorus, bridge and outro) of the musical work. In other words, the user may be required to accurately estimate the beats, bars or measures, and then cause the musical work to be segmented at an appropriate time between respective beats, bars or measures. This may be difficult for someone perhaps lacking patience, a particularly musical ear, or the appropriate training. In addition, availability of the foregoing functionality in portable devices (e.g., cellular telephones, personal digital assistants (PDAs), pagers, and the like) is currently rather limited.
A further need, therefore, exists for a user interface that enables even an amateur to perform the above-described functionality with skill. In addition, a need exists for such a user-friendly user interface that can be used in connection with a user's mobile or portable device.
In addition to the foregoing, it is often desirable for an individual to be able to share the variations or remixes he or she has created with others. However, at least two issues arise when a user attempts to do so. The first is the fact that the original music file is usually copyright protected and, therefore, cannot legally be transmitted to another individual. In order to legally share variations of a copyright protected work, therefore, a need exists for a technique for so sharing that does not require any part of the original work to be transmitted.
The second issue relates to the size of most files associated with a variation or remix. Typically the remix or variation is at least as large as the original musical work or file, since it often includes more segments of the musical work than the original. Sharing the variation or remix with others can, therefore, become rather cumbersome. A further need, therefore, exists for a way in which to share variations or remixes of an original musical work that reduces the amount of data that must be transmitted.
In general, exemplary embodiments of the present invention provide an improvement over the known prior art by, among other things, providing a method, device, system and apparatus for creating and sharing variations of a music file, wherein a variation metadata file is created that includes a relatively limited amount of data, none of which includes any portion of the original musical work, and that can be subsequently stored, transmitted and used in order to recreate the variation or remix of the original musical work. In particular, according to exemplary embodiments of the present invention, as a user skips, repeats and/or loops various beats, measures and/or segments of a musical work, the beats, measures and/or segments actually played are recorded. An index can then be associated with each beat, measure and/or segment recorded, and a variation metadata file may be created based on a combination of these indices. The order and manner in which the indices are combined in the variation metadata file is reflective of the order and manner in which the various beats, measures and/or segments were played when creating the variation. In order to use the variation metadata file to later recreate the variation, a rhythm metadata file including both an index associated with each beat, measure and segment of the original musical work, as well as an indication of a location within the musical work associated with each beat, measure and segment, is accessed in order to determine the location within the original musical work of the beats, measures and/or segments of the variation, as indicated by the indices of the variation metadata file.
In accordance with one aspect, a method is provided of creating and sharing one or more variations of a music file. In one exemplary embodiment, the method includes: (1) enabling a user to create a variation of a music file, wherein the music file comprises one or more segments, respective segments further comprise one or more measures and respective measures further comprise one or more beats, and wherein the variation includes a combination of at least one of the beats, measures or segments of the music file; and (2) creating a variation metadata file that includes an index associated with respective at least one beat, measure or segment of the combination and indicates an order in which the at least one beat, measure or segment are combined, wherein the variation metadata file is capable of being stored and transmitted separately from the music file.
In one exemplary embodiment, the method further includes analyzing the music file to determine a location within the music file corresponding with respective beats, measures and segments of the music file; assigning an index to respective beats, measures and segments; and creating a rhythm metadata file associated with the music file, wherein the rhythm metadata file includes a combination of the assigned index and an indication of the determined location within the music file corresponding with respective beats, measures and segments of the music file. The indication of the determined location within the music file corresponding with respective beats, measures and segments may, in one exemplary embodiment, include some combination of a time associated with a beginning of respective beats, measures and segments, a time associated with an end of respective beats, measures and segments, a number of beats per measure, and a number of measures per segment.
In another exemplary embodiment, the method further includes playing the music file. In this exemplary embodiment, enabling a user to create a variation of the music file comprises enabling the user to vary at least one of the beats, measures or segments of the music file currently playing, such that playing the music file comprises playing the music file as varied. The method of this exemplary embodiment may further include recording at least one beat, measure or segment played; determining an index associated with respective at least one beat, measure or segment recorded, based at least in part on the rhythm metadata file associated with the music file; and combining the at least one index into the variation metadata file, such that the combination of indices reflects the at least one beat, measure or segment played and an order in which the at least one beat, measure or segment were played.
In accordance with another aspect, a user interface is provided for creating one or more variations of a music file. In one exemplary embodiment, the user interface includes a plurality of input elements, wherein respective input elements are configured to receive at least one of a plurality of commands for varying a music file that includes one or more segments, respective segments include one or more measures and respective measures include one or more beats. The user interface of this exemplary embodiment further includes an output element configured to output a variation of the music file in response to the at least one command, such that the variation comprises one or more beats, measures and segments of the music file that have been varied based at least in part on a location within the music file associated with at least one beat, measure or segment of the music file.
In one exemplary embodiment, at least one of the plurality of input elements includes a repeat element configured to receive a command to repeat at least one beat, measure or segment of the music file, and the output element is configured to repeat the at least one beat, measure or segment based at least in part on a location associated with a beginning of the at least one beat, measure or segment. In another exemplary embodiment, at least one of the plurality of input elements includes a skip forward element configured to receive a command to skip forward at least one beat, measure or segment of the music file. The output element of this exemplary embodiment, in turn, is configured to output a current beat of the music file prior to outputting a next beat, measure or segment, as determined based at least in part on a location within the music file associated with a beginning of the next beat, measure or segment. In yet another exemplary embodiment, at least one of the plurality of input elements includes a skip back element configured to receive a command to skip back at least one beat, measure or segment of the music file. The output element of this exemplary embodiment, in turn, is configured to output a current beat of the music file prior to outputting a previous beat, measure or segment, as determined based at least in part on a location within the music file associated with a beginning of the previous beat, measure or segment
According to yet another aspect, an apparatus is provided for creating and sharing one or more variations of a music file. In one exemplary embodiment the apparatus includes a processing element configured to: (1) record a combination of one or more beats, measures and segments of a music file in an order and a combination in which the beats, measures and segments are currently being played; (2) determine an index associated with respective beats, measures and segments of the combination; and (3) create a variation metadata file that includes the associated indices determined, wherein the indices are combined in the order and combination in which the corresponding beats, measures and segments were played.
According to another aspect, an apparatus for recreating one or more variations of a music file is provided. In one exemplary embodiment the apparatus includes a processing element configured to: (1) receive a variation metadata file comprising one or more indices associated with a respective one or more beats, measures or segments of a variation of a music file; (2) access a rhythm metadata file comprising a combination of one or more indices associated with a respective one or more beats, measures and segments of the music file and an indication of a location within the music file associated with respective beats, measures and segments of the music file; and (3) determine, based at least in part on the variation metadata file and the rhythm metadata file, a location within the music file corresponding with respective beats, measures and segments of the variation of the music file.
In accordance with another aspect, a device is provided that is capable of creating and sharing one or more variations of a music file. In one exemplary embodiment, the device includes: (1) a processor; (2) a user interface configured to enable a user to create a variation of a music file, wherein the music file includes one or more segments, respective segments comprise one or more measures and respective measures comprise one or more beats, and wherein the variation includes a combination of at least one of the beats, measures or segments of the music file; and (3) a memory in communication with the processor, wherein the memory stores an application executable by the processor, and wherein the application is configured, upon execution, to create a variation metadata file that comprises an index associated with respective at least one beat, measure or segment of the combination and indicates an order in which the at least one beat, measure or segment are combined. In one exemplary embodiment, the variation metadata file is capable of being stored and transmitted separately from the music file and further of being used to recreate the variation of the music file.
In accordance with another aspect, a system is provided for creating and sharing one or more variations of a music file. In one exemplary embodiment, the system includes a first and second device, wherein the first device is configured to: (1) enable a user to create a variation of a music file, wherein the music file includes one or more segments, respective segments further comprise one or more measures, and respective measures further comprise one or more beats, and wherein the variation includes a combination of at least one of the beats, measures or segments of the music file; (2) create a variation metadata file that includes an index associated with respective at least one beat, measure or segment of the combination and an indication of an order in which the at least one beat, measure or segment are combined; and (3) separately transmit the variation metadata file. In one exemplary embodiment, the second device is configured to receive the variation metadata file and to recreate the variation of the music file using the variation metadata file received.
In accordance with yet another aspect, a computer program product is provided for creating and sharing one or more variations of a music file. The computer program product contains at least one computer-readable storage medium having computer-readable program code portions stored therein. The computer-readable program code portions of one exemplary embodiment include: (1) a first executable portion for enabling a user to create a variation of a music file, wherein the music file comprises one or more segments, respective segments include one or more measures, and respective measures further include one or more beats, and wherein the variation includes a combination of at least one of the beats, measures or segments of the music file; and (2) a second executable portion for creating a variation metadata file that includes an index associated with respective at least one beat, measure or segment of the combination and indicates an order in which the at least one beat, measure or segment are combined, wherein the variation metadata file is capable of being stored and transmitted separately from the music file and further of being used to recreate the variation of the music file.
Having thus described exemplary embodiments of the invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:
Exemplary embodiments of the present invention now will be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the inventions are shown. Indeed, exemplary embodiments of the invention may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements. Like numbers refer to like elements throughout.
Overview:
In general, exemplary embodiments of the present invention provide a technique for creating and sharing variations of a music file that is easy to use and does not require that any copyrights in the original work be violated. In particular, according to exemplary embodiments, a user is capable of manipulating or varying one or more beats, measures or segments of a musical work while the musical work is being played. The user is further able to do so in a manner that relies on annotated rhythmic information associated with the musical work to ensure that the variation or remix remains continuous and pleasing to the listener. In one exemplary embodiment, the rhythmic information relied on includes, for example, locations within the musical work associated with each beat, measure and segment of the musical work, as well as a corresponding indices for each beat, measure and segment.
In addition, the user is able to capture, as metadata, the resulting combination of beats, measures and/or segments of the variation in a format that is condense and easily transmitted. In particular, according to exemplary embodiments, a variation metadata file is created that includes merely a list of indices associated with respective beats, measures and/or segments of the variation created in an order and combination that is representative of the corresponding variation. Using the rhythmic information associated with the original musical work, the user, or some other party to whom the user has transmitted the variation metadata file, may recreate the variation by, for example, cross-referencing the indices of the variation metadata file with the indices and locations of the rhythmic metadata file.
Exemplary embodiments of the present invention are, therefore, advantageous at least because they enable a user to easily create variations of a musical work that maintain the rhythmic integrity of the original work. Exemplary embodiments further enable users to share these variations without having to transmit any portion of the original musical work and, therefore, potentially violate copyrights in the original work. A further advantage is that the amount of information that must be transmitted in order to share the variation is further reduced by the fact that the user need not transmit any timing information (e.g., specific beat, measure, segment or loop times) associated with the variation, since the user can assume that the recipient either possesses, or is capable of accessing, such information separately (i.e., in the form of the rhythm metadata file).
Method of Creating and Sharing Variations of a Music File
Reference is now made to
In a first step (Step 101a), the music file is analyzed to determine a location associated with respective beats, measures and segments of the music file. As discussed above, a music file comprises a plurality of beats (or tactus pulses), one or more measures, which each typically comprise a combination of one or more beats forming a rhythmic pattern, and one or more segments, defined as sections longer than one measure and including, for example, the intro, verse, chorus, bridge and outro. Determining the location associated with respective beats, measures and segments may involve determining the beginning time of each beat, measure and segment (i.e., the amount of time from the beginning of the music file to the start of each beat, measure and segment), as well as the ending time of each beat, measure and segment. Alternatively, only the beginning time may be determined, as well as, for example, the number of beats per measure and/or the number of measures per segment.
The choruses and other sections of the music file can be annotated by experts or analyzed automatically using, for example, the method described in Goto. The method in Goto may return only repeating sections of the music file, but the remaining sections not explained by the method of Goto can be assigned as their own sections. The section boundaries returned by the method of Goto do not necessarily coincide with the times of measures or beats, and thus the boundaries can be rounded to the nearest beat or measure. If there is overlap in the sections returned by the method of Goto, then these overlapping sections can be combined into longer sections that do not overlap.
Once the location of each beat, measure and segment has been determined, in Step 101b, an index may further be assigned to each. Indices may include, for example, B1, B2 . . . BQ, for each Q non-overlapping beats of the music file, M1, M2 . . . MP, for each of P non-overlapping measures of the music file, S1, S2 . . . SN, for each N non-overlapping segments of the music file and C1, C2 . . . CR, for each R choruses of the music file, wherein Q, P, N and R are positive integers greater than or equal to one. Alternatively, pulses of a smaller time scale or level may be represented as decimal or fractional values of the pulses of a larger time scale or level. For example, beats may be represented as decimal values of the various measures (e.g., M1.1, M1.2, M1.3 . . . M1.E, where M1.1 denotes the first beat of the first measure and M1.E denotes the last or end beat of the first measure). Measures may further be represented as decimal or fractional values of the various segments (e.g., S1.1, S1.2, S1.3 . . . S1.E, where S1.1 denotes the first measure of the first segment and S1.E denotes the last or end measure of the first segment). Beats, measures and segments may further be combined into a single index having two decimal points (e.g., S1.1.1, S1.1.2 . . . S1.1.E, S1.2.1 . . . S1.E.1 . . . S.1.E.E, wherein the first number represents the segment, the first decimal value represents the measure, and the second decimal value represents the beat).
To further illustrate, the following Table 1 provides an example of how the beats and measures of a particular music file may be annotated in accordance with exemplary embodiments of the present invention. As shown, the music file has four beats per measure corresponding to, for example, a 4/4 signature where each measure consists of four quarter notes, wherein B denotes a beat and M denotes the first beat of a measure.
Table 2 below provides a further example of a segment structure of a musical work. As shown, in this example, the fourth segment S4 coincides with the first chorus C1 of the music file, while the seventh segment S7 coincides with the second chorus C2.
As one of ordinary skill in the art will recognize, the foregoing is just one example of how indices may be assigned to the various beats, measures and/or segments of a music file. Other techniques and indices may similarly be used without departing from the spirit and scope of the present invention. For example, another metrical level may be added below the beat, such that each beat would be divided into a number of tatums, or temporal atoms, typically corresponding to ⅛th or 1/16th notes. In this exemplary embodiment, the indices or representations would have another level, such that S1.1.1.1 would denote the first tatum of the first beat of the first measure of the first segment. As another example, it may be possible to implement exemplary embodiments of the present invention in terms of beats and measures only, thus eliminating the designation of segments, or as beats and segments only, thus eliminating the designation of measures. As is thus illustrated, many similar conventions may likewise be used in order to annotate the beats and rhythmic pattern of a musical work without departing from the spirit and scope of the present invention.
Returning to
The example above illustrates a rhythm metadata file corresponding with a musical excerpt whose length is 33.5 seconds. The excerpt consists of three sections (S1, S2 and S3), wherein the third section (S3) corresponds with the first chorus (C1). The first two sections (S1 and S2) each consists of four measures, while the third section (S3) consists of six measures. Each measure is further divided into four beats. The first two sections (S1 and S2) indicate the start times of each beat, while the third section (S3) indicates only the start time of the first beat in conjunction with the time interval between beats. The beat interval indicates the time difference, in seconds, between the start times of two successive beats. The times of individual beats within each measure can then be calculated based on the time of the first beat, the beat interval, and the number of beats per measure. For example, the beat start times for the sixth measure (M6) of section three (S3) can be calculated as 31.1402, 31.7402, 32.3402, 32.9402 seconds, since, as indicated in the exemplary rhythm metadata file shown above, there are four beats in the sixth measure, the beat interval is 0.6000 seconds, and the start time of the first beat is 31.1402 seconds. The beat ending times are not separately indicated in the above example, since a beat ends just before the next beat starts and, therefore, can be easily ascertained. The ending time of a measure can be taken as the ending time of its last beat. A measure ends just before the beginning of the first beat in the next measure. In the example shown above, the section C1 (i.e., the first chorus) does not have its own measure and beat annotations, but rather just refers to section three (S3).
In one exemplary embodiment, the foregoing steps of
The overall process illustrated in
The steps which may be taken by the user in order to so manipulate the beats, measures or segments are shown in
As shown, and as is discussed in more detail below, the user interface may include, for example, a loop input element (e.g., button or icon) 402, a previous measure input element 404, and a next measure input element 406. Additional input elements (e.g., buttons or icons) may include, for example, a beat fast forward input element 408, a beat rewind input element 410, as well as one or more standard input elements associated with a typical music player 412 (e.g., stop, pause, play, previous track, rewind, fast forward and next track). In one exemplary embodiment, shown in
Referring to
After playing the first beat of the previous or next measure, in one exemplary embodiment, the mobile device will determine, in Step 103e, if the user has released the previous or next measure button 404, 406. If not, indicating that the user wishes to again skip to the previous or next measure, the device will first determine whether the current measure is the first (in this instance where the user has actuated the previous measure button 404) or the last (in the instance where he or she has actuated the next measure button 406) measure of the music file (Step 103f), and if so, end the music file (Step 103k), since there is no where left to skip. If not, the music player will again skip to the previous or next measure and play the first beat of that measure (i.e., the process will return to Step 103d).
Returning to Step 103b, if it is determined that the user has not selected the previous or next measure button 404, 406, it is next determined, in Step 103g, if the song or music file is currently at the end of a measure. In general, this may be determined by accessing the rhythm metadata file associated with the music file that was created in Step 101 of
In one exemplary embodiment, a user may actuate the loop button 402 once in order to place the music player into loop mode, causing the music player to continue looping the current measure until the user again actuates the loop button 402. In another exemplary embodiment, the user may be required to continuously actuate (e.g., hold down) the loop button 402 for the length of time for which he or she desires to loop the current measure. In yet another exemplary embodiment, the user may hold down the loop button 402 for a period of time to indicate a number of measures he or she desires to loop. For example, the user may hold down, or otherwise actuate, the loop button 402 throughout the duration of two measures. Upon releasing the loop button 402, the music player may begin looping or repeating those two measures. In another alternative embodiment, a user may be able to actuate the loop button 402 for a certain number of beats in order to indicate the number of measures to be repeated or looped. To illustrate, a user may actuate the loop button 402 for three beats of a particular measure, this may be taken by the music player as an indication that the user desires to loop or repeat three measures, beginning with the current measure. As one of ordinary skill in the art will recognize, the foregoing is not limited to looping measures. In contrast, a user may similarly actuate the loop button 402 in order to repeat one or more pulses of a smaller (e.g., beats) or larger (e.g., segments) time scale or level as the measure.
Returning to Step 103h, if it is determined that the user has not actuated the loop button 402, the process will continue to Step 103j where it is determined whether the music player has reached the end of the music file. If so, the process ends (i.e., the music player will stop). (Step 103k). If not, the process returns to Step 103a, where the music file continues to be played as the original music file, until it is determined that the user wishes to either loop a particular beat, measure or segment or skip ahead or back one or more beats, measures or segments.
In addition to the foregoing, in one exemplary embodiment, when a jump is made from a location in the music file to some other location (e.g., from the end of the first beat of a measure to the beginning of the next measure) known methods of crossfading may be applied to make the transition more pleasing for the listener.
The foregoing provides just one manner in which a user may vary the beats, measures or segments of a music file in real time (i.e., as the music file is being played) in accordance with exemplary embodiments of the present invention. In general, the user can create any combination of beats, measures or segments using the techniques discussed above. An advantage of exemplary embodiments is that the user is able to do so using an easy to understand interface that enables the user to skip between and repeat beats, measures and segments of a music file in a manner that does not disrupt the continuity of the music file.
Returning now to
As shown, the variation metadata file is created by first recording the beats, measures and segments played by the user while creating the variation or remix. (Step 104a). In one exemplary embodiment, in order for Step 104a to be performed, the user must first actuate a record button on the user interface (not shown) in order to instruct the music player to begin creating the variation metadata file. Alternatively, the beat, measure and segment information may automatically be recorded any time a user begins playing a music file. In the latter instance, at the end of the process, the user may be given the option of deleting the variation metadata file created, or saving it to a particular location. In yet another alternative embodiment, the recording of the variation metadata may be initiated once the user first presses the loop button 402, or once he or she presses either the previous or next measure buttons 404, 406.
Regardless of how the recording is initiated, in Step 104b, an index associated with each beat, measure or segment recorded may then be determined by, for example, consulting the rhythm metadata file associated with the music file. Finally, the indices are combined, in Step 104c, into the variation metadata file in such a manner that the order and combination of indices reflects, for example, the order in which the beats, measures and segments were played, a number of times various beats, measures or segments were repeated or looped, and the like.
The following Table 3 provides several examples of variation metadata files, which may be created in accordance with exemplary embodiments of the present invention, as well as a description of each corresponding variation or remix.
As shown, each variation metadata file may comprise a relatively small amount of data, thus enabling a user to store dozens of variations for an original musical work with minimal storage requirements. In addition, the variation metadata files may be in the form of simple text, enabling the files to be transmitted as text messages (e.g., E-mails, Short Message Service (SMS) messages, Instant Messages (IMs), or the like), and edited using, for example, a simple text editor operating on the user's device. This would enable a user, for example, to change a variation of the music file that he or she has created without having to replay the music file or use the above-described user interfaces to loop and/or skip beats, measures or segments of a currently playing music file. The user can simply add, remove or change the combination of indices of the variation metadata file in order to affect the change to the created variation.
In addition to the foregoing, as shown in the first exemplary variation metadata file of Table 3, an identifier associated with the original work may also be included in the variation metadata file. In one exemplary embodiment, the identifier may comprise a Uniform Resource Identifier (URI) or Locator (URL), the title of the original music file, or a similar identifier, which can later be used by the creator of the variation, or a party to whom he or she transmits the variation metadata file, to identify the original musical work. In one exemplary embodiment, the identifier may comprise an acoustic fingerprint, based on which the music player can search the device and/or a music service in order to locate the musical work. However, in this exemplary embodiment, because the acoustic fingerprint cannot be represented in a textual format (since it is typically binary), the identification may be communicated separately from the variation metadata file (e.g., as an attachment to the E-mail including the variation metadata file in the body of the email).
Returning again to
The friend or family member receives the variation metadata file, in Step 107, for example, as an E-mail, SMS message or IM. Thereafter, assuming the recipient already possesses the original musical work or is capable of locating and downloading it (e.g., via an online retail supplier), the recipient first accesses the rhythm metadata file associated with the original music file. (Step 108). As noted above, the recipient's device may have created the rhythm metadata file after downloading or receiving the music file. Alternatively, the source of the music file may have provided the rhythm metadata file to the recipient in conjunction with the actual music file. Alternatively, the recipient of the variation metadata file may request the rhythm metadata file from the party who sent the variation metadata file. Regardless of how the rhythm metadata file has been obtained, once the user has access to the rhythm metadata file, he or she is then able to recreate the variation of the music file, in Step 109, using the variation metadata file received in conjunction with the rhythm metadata file.
In particular, reference is made to
Overall System and Mobile Device:
Referring to
The MSC 16 can be coupled to a data network, such as a local area network (LAN), a metropolitan area network (MAN), and/or a wide area network (WAN). The MSC can be directly coupled to the data network. In one typical embodiment, however, the MSC is coupled to a Packet Control Function (PCF) 18, and the PCF is coupled to a Packet Data Serving Node (PDSN) 19, which is in turn coupled to a WAN, such as the Internet 20. In turn, devices such as processing elements (e.g., personal computers, server computers or the like) can be coupled to the mobile station 10 via the Internet. For example, the processing elements can include one or more processing elements (e.g., a server) associated with an online retail source or supplier of music files 22. As discussed above, the online retail supplier 22 may provide one or more music files, and their corresponding rhythm metadata files, for downloading by a user to his or her mobile device. As will be appreciated, the processing elements can comprise any of a number of processing devices, systems or the like capable of operating in accordance with embodiments of the present invention.
The BS 14 can also be coupled to a signaling GPRS (General Packet Radio Service) support node (SGSN) 30. As known to those skilled in the art, the SGSN is typically capable of performing functions similar to the MSC 16 for packet switched services. The SGSN, like the MSC, can be coupled to a data network, such as the Internet 20. The SGSN can be directly coupled to the data network. In a more typical embodiment, however, the SGSN is coupled to a packet-switched core network, such as a GPRS core network 32. The packet-switched core network is then coupled to another GTW, such as a GTW GPRS support node (GGSN) 34, and the GGSN is coupled to the Internet.
Although not every element of every possible network is shown and described herein, it should be appreciated that the mobile station 10 may be coupled to one or more of any of a number of different networks. In this regard, mobile network(s) can be capable of supporting communication in accordance with any one or more of a number of first-generation (1G), second-generation (2G), 2.5G and/or third-generation (3G) mobile communication protocols or the like. More particularly, one or more mobile stations may be coupled to one or more networks capable of supporting communication in accordance with 2G wireless communication protocols IS-136 (TDMA), GSM, and IS-95 (CDMA). Also, for example, one or more of the network(s) can be capable of supporting communication in accordance with 2.5G wireless communication protocols GPRS, Enhanced Data GSM Environment (EDGE), or the like. In addition, for example, one or more of the network(s) can be capable of supporting communication in accordance with 3G wireless communication protocols such as Universal Mobile Telephone System (UMTS) network employing Wideband Code Division Multiple Access (WCDMA) radio access technology. Some narrow-band AMPS (NAMPS), as well as TACS, network(s) may also benefit from embodiments of the present invention, as should dual or higher mode mobile stations (e.g., digital/analog or TDMA/CDMA/analog phones).
One or more mobile stations 10 (as well as one or more processing elements, although not shown as such in
Although not shown in
Reference is now made to
The mobile station includes various means for performing one or more functions in accordance with exemplary embodiments of the present invention, including those more particularly shown and described herein. It should be understood, however, that one or more of the entities may include alternative means for performing one or more like functions, without departing from the spirit and scope of the present invention. More particularly, for example, as shown in
It is understood that the processing device 308, such as a processor, controller or other computing device, includes the circuitry required for implementing the video, audio, and logic functions of the mobile station and is capable of executing application programs for implementing the functionality discussed herein. For example, the processing device may be comprised of various means including a digital signal processor device, a microprocessor device, and various analog to digital converters, digital to analog converters, and other support circuits. The control and signal processing functions of the mobile device are allocated between these devices according to their respective capabilities. The processing device 308 thus also includes the functionality to convolutionally encode and interleave message and data prior to modulation and transmission. The processing device can additionally include an internal voice coder (VC) 308A, and may include an internal data modem (DM) 308B. Further, the processing device 308 may include the functionality to operate one or more software applications, which may be stored in memory. For example, the controller may be capable of operating a connectivity program, such as a conventional Web browser. The connectivity program may then allow the mobile station to transmit and receive Web content, such as according to HTTP and/or the Wireless Application Protocol (WAP), for example.
The mobile station may also comprise means such as a user interface including, for example, a conventional earphone or speaker 310, a ringer 312, a microphone 314, a display 316, all of which are coupled to the controller 308. The user input interface, which allows the mobile device to receive data, can comprise any of a number of devices allowing the mobile device to receive data, such as a keypad 318, a microphone 314, or other input device. In embodiments including a keypad, the keypad can include the conventional numeric (0-9) and related keys (#, *), and other keys used for operating the mobile station and may include a full set of alphanumeric keys or set of keys that may be activated to provide a full set of alphanumeric keys. In addition, the keypad 318 of exemplary embodiments of the present invention may further include one or more keys capable of being used to vary the beats, measures or segments of a currently playing music file, and may resemble those illustrated in
The mobile station 10 may further include a music player 326 capable of playing a music file and performing a plurality of commands with respect to the currently playing music file (e.g., pause, stop, fast forward, rewind, skip track, etc.). In particular, the music player 326 may comprise various means, including entirely hardware, entirely software, or any combination of software and hardware, for performing one or more functions in accordance with exemplary embodiments. For example, as discussed above, the music player 326 may comprise various means for skipping forward or back a beat, measure or segment in a music file, or repeating a beat, measure or segment, upon receiving instructions to do so from the user via, for example, the user interface of
The mobile station 10 may further include a text editor 328, likewise comprising various means, including entirely hardware, entirely software, or any combination of hardware and software, for enabling a user to edit a variation metadata file that has been created, for example, in the method discussed above.
Although not shown, the mobile station may also include a battery, such as a vibrating battery pack, for powering the various circuits that are required to operate the mobile station, as well as optionally providing mechanical vibration as a detectable output.
The mobile station can also include means, such as memory including, for example, a subscriber identity module (SIM) 320, a removable user identity module (R-UIM) (not shown), or the like, which typically stores information elements related to a mobile subscriber. In addition to the SIM, the mobile device can include other memory. In this regard, the mobile station can include volatile memory 322, as well as other non-volatile memory 324, which can be embedded and/or may be removable. For example, the other non-volatile memory may be embedded or removable multimedia memory cards (MMCs), Memory Sticks as manufactured by Sony Corporation, EEPROM, flash memory, hard disk, or the like. The memory can store any of a number of pieces or amount of information and data used by the mobile device to implement the functions of the mobile station. For example, the memory can store an identifier, such as an international mobile equipment identification (IMEI) code, international mobile subscriber identification (IMSI) code, mobile device integrated services digital network (MSISDN) code, or the like, capable of uniquely identifying the mobile device.
The memory can also store content. For example, they memory may store one or more rhythm metadata files created, for example, in the manner discussed above in relation to
In addition, the memory may store computer program code for an application and other computer programs. For example, in one embodiment of the present invention, the memory may store computer program code for performing any one or more of the steps discussed above with reference to
The method, device, system and apparatus of exemplary embodiments of the present invention are primarily described in conjunction with mobile communications applications. It should be understood, however, that the method, device, system and apparatus of embodiments of the present invention can be utilized in conjunction with a variety of other applications, both in the mobile communications industries and outside of the mobile communications industries. For example, the method, device, system and apparatus of exemplary embodiments of the present invention can be utilized in conjunction with wireline and/or wireless network (e.g., Internet) applications.
Conclusion:
As described above and as will be appreciated by one skilled in the art, embodiments of the present invention may be configured as a method, device, system and apparatus. Accordingly, embodiments of the present invention may be comprised of various means including entirely of hardware, entirely of software, or any combination of software and hardware. Furthermore, embodiments of the present invention may take the form of a computer program product on a computer-readable storage medium having computer-readable program instructions (e.g., computer software) embodied in the storage medium. Any suitable computer-readable storage medium may be utilized including hard disks, CD-ROMs, optical storage devices, or magnetic storage devices.
Exemplary embodiments of the present invention have been described above with reference to block diagrams and flowchart illustrations of methods, apparatuses (i.e., systems) and computer program products. It will be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, respectively, can be implemented by various means including computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create a means for implementing the functions specified in the flowchart block or blocks.
These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including computer-readable instructions for implementing the function specified in the flowchart block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks.
Accordingly, blocks of the block diagrams and flowchart illustrations support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams and flowchart illustrations, and combinations of blocks in the block diagrams and flowchart illustrations, can be implemented by special purpose hardware-based computer systems that perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.
Many modifications and other embodiments of the inventions set forth herein will come to mind to one skilled in the art to which these exemplary embodiments of the invention pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the embodiments of the invention are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.