Method of storing data in a multimedia file using relative timebases

Abstract

The invention concerns a method for storing data in a multimedia file, the multimedia file containing an absolute time base indicator and at least a track wherein the data are stored. Said data comprise time values. The method is characterised in that it consists in associating with each track; at least a relative time base indicator which is a function of said absolute time base, and in determining some or all the time values contained in a track, with respect to a relative time base indicator associated with said track.

Description

[0001] The present invention relates to a method of storing data in a multimedia file. It applies with particular benefit to onboard systems such as mobile telephones, pocket computers and any other device that has to have multimedia capabilities and for which the size of multimedia files and the computing power needed to process them constitute a problem.

[0002] There are many methods of storing data in monomedia files, i.e. files concerning only one particular type of data. Examples that may be cited include the JPEG (Joint Photographic Expert Group) format for storing images, the WAV format for storing sound data, the RTF (Rich Text File) format for storing text, etc.

[0003] There are also methods of storing data in multimedia files, i.e. files integrating data of different kinds. An example that may be cited is the MPEG (Motion Picture Expert Group) format integrating sound and video data.

[0004] MIDI (Musical Instrument Digital Interface) files store sound data in files structured into tracks, each track usually corresponding to one musical instrument. The data contained in each track can be time values (i.e. durations of notes or times between successive notes). These time values are given as a function of an absolute timebase whose value is inserted into a header of the MIDI file in the form of two fields, a time signature and a tempo.

[0005] Each time value is coded in the form of the multiplicand value of the absolute timebase. For example, if the timebase is 100 ms, a duration of 1 s is coded 10.

[0006] The absolute timebase principle works well only if all the time values are of the same order of magnitude. This is generally the case in a MIDI file, in which all of the data concerns sound.

[0007] However, in the context of a multimedia file incorporating data of different kinds, this absolute timebase principle is no longer satisfactory.

[0008] This is because the time values can be very heterogeneous, as a function of the type of data. For example, time values concerning a sequence of images ore generally a few seconds, whereas time values for musical sequences are around 100 ms.

[0009] If the absolute timebase principle as described in the MIDI file specifications is used, the timebase must be less then or equal to the smallest time value in order to cater for all time values.

[0010] Cons quently, the highest values are th n coded on a large number of bits.

[0011] For example, with an absolute tim base of 100 ms, a time value of 10 seconds is coded 100. Consequently, the time values must be coded on a minimum of seven bits per value.

[0012] In the context of an onboard system, there are severe constraints on file size:

[0013] Firstly, the memory available is limited for reasons of overall size and battery life.

[0014] Secondly, multimedia files may need to be downloaded from a server center, and the call time is directly related to their size.

[0015] The object of the present invention is to reduce the size of multimedia files whilst enabling the storage of all types of data.

[0016] To this end, the invention provides a method of storing data in a multimedia file containing an absolute timebase indicator and at least one frock in which said data is stored. Said data includes time values.

[0017] The method is characterized in that each track is associated with at least one relative timebase indicator, as a function of said absolute timebase, and in that some or all time values contained in a track are determined relative to a relative timebase indicator associated with said track.

[0018] The invention and its advantages will become more clearly apparent in the course of the following description, which is given with reference to the accompanying drawings.

[0019] FIG. 1 is a diagram showing a multimedia file conforming to the invention.

[0020] FIG. 2 is a detailed view of a track contained in a multimedia file according to the invention.

[0021] FIG. 3 shows a different embodiment of the invention.

[0022] According to the invention, the data can be time values. The time values con represent a duration, a start value or an end value of a presentation to a user, or other data (image, sound, text, etc.). It con thus be the time of display of an image, or the time for which a musical note is held, or the time at which the note starts, or the wait time between two events, etc.

[0023] FIG. 1 is a diagram showing the structure of a multimedia file F according to the invention which contains a header H and a plurality of tracks T1, T2, . . . , Tn.

[0024] The header H includes diverse information common to all tracks (identification, etc.) that are not detailed separately apart from an absolute timebase (ATB) indicator.

[0025] The ATB determines the smallest time value that can be present in the multimedia file. It con be calculated as the highest common factor (HCF) of all time values in the multimedia file F.

[0026] As previously stated, the multimedia file F further includes a set of tracks T1, T2, . . . Tn (possibly a single track). Each of the tracks can be dedicated to a single type of data. For example, track T1 can include a sequence of images, track T2 con be a MIDI track, track Tn can include sequences of text messages, etc. These various tracks con be intended to be read and presented to the user simultaneously.

[0027] The tracks may contain time values associated with other data contained in the track. This association con take various forms:

[0028] Each data item can be systematically followed by a numerical value. This method can be used to specify the duration of presentation of a data item, for example (duration of a note, etc.).

[0029] Time values can also be inserted optionally, as and when required. This method con be used to specify a time-delay between two presentations of data, for example. The omission of this time value can then signify that the two data items must be presented simultaneously (as in the case of a chord mode up of several notes, for example).

[0030] These two possibilities con be combined and it is entirely possible to use other arrangements without departing from the scope of the invention.

[0031] FIG. 2 shows the structure of a track contained in a multimedia file conforming to the invention. In this example, the track contains only sound data.

[0032] The track T1 includes a header THi and data relating to sound. A first field Nh1 represents the pitch of a first note and a second field Nd1 represents its duration. Similarly, the fields Nh2 and Nd2 define a second note.

[0033] The field D1 represents a time-delay, i.e. a wait time before presenting the subsequent notes of the track.

[0034] The fields Nh3 and Nd3 respectively represent the pitch and the duration of a third note.

[0035] The fields defining a note or a time can therefore follow on in sequence in the track Ti.

[0036] The header THi of the track Ti includes a relative timebase indicator RTBi. The value of the relative timebase is given as a function of the absolute timebase ATB.

[0037] In one embodiment of the invention, durations are determined as a function of th relative timebase RTBi and the times between notes only as a function of the absolute tim base ATB.

[0038] Accordingly, the time values Nd1, Nd2, Nd3 are determined with respect to the relative timebase RTBi while the time value D1 is determined with respect to the absolute timebase ATB.

[0039] Similarly, in FIG. 1, the tracks T1, T2, . . . Tn include respective headers TH1, TH2, . . . THn. Each header contains a respective relative timebase indicator RTB1, RTB2, . . . RTBn.

[0040] A different embodiment could store these timebase indicators outside the track headers, for example in a table contained in the header H of the multimedia file.

[0041] Each track additionally contains time values v11, v12, v21, vn1 determined relative to the relative timebases. A time value is preferably determined relative to the timebase indicator contained in the same track as itself.

[0042] The table below gives one numerical example for the time values represented in FIG. 1:

	V11	100	ms
	V12	150	ms
	V21	0.5	s
	Vn1	6	s

[0043] The absolute timebase is defined as the highest common factor of all time values. Thus here the absolute timebase indicator ATB takes the value 50 ms.

[0044] The relative timebases RTB1, RTB2 and RTBn are then defined as the highest common factors of the time values contained in their respective tracks,

[0045] Thus there is a relative timebase equal to 50 ms for track 1,500 ms for track 2, and 6 s for track n.

[0046] The values of the relative timebase indicators are therefore:

[0047] RTB1=1

[0048] RTB2=10

[0049] RTBn=120

[0050] The time values ore then determined relative to these relative timebase indications, and the following table of values is obtained:

V11 2
V12 3
V21 1
Vn1 1

[0051] If the time values had been coded using only an absolute timebase, it would have been necessary to code time values from twice to 120 times the absolute timebase. It would therefore have been necessary to code the time values on seven bits.

[0052] Using relative timebases, the time values range from only one to three and therefore can be coded on only two bits.

[0053] Consequently, the method according to the invention provides a saving of 5*(7 bits−2 bits)−3*7 bits=4 bits.

[0054] The first term represents the saving on the five time values present. The second term is the loss due to adding relative timebase indicators to the headers of the three tracks T1, T2 and Tn.

[0055] If the number of time values increases, the loss due to this second term decreases in the same proportion.

[0056] In a real situation, i.e. that of a file with a few hundred kilobytes or even several megabytes, the saving can be as high as around 20%.

[0057] FIG. 3 shows a different embodiment in which the relative timebase indicators can be inserted into a track T outside the header. In this case, a plurality of timebase indicators B1, B2 can easily be associated with the some time T.

[0058] To be more precise, each relative timebase indicator is uniquely associated with a portion of the track. In FIG. 3, for example, the timebase indicator B1 is associated with the portion P1, the timebase indicator B2 with the portion P2, and so on.

[0059] A timebase indicator preferably defines an associated portion that follows it immediately and which terminates at the next timebase indicator.

[0060] In other words, the time values contained in a track are defined relative to the timebase indicator that immediately precedes it.

[0061] An advantage of this kind of implementation is to be easily able to take account of local variations of the timing of the multimedia data to be stored. Thus in the case of musical data, the tempo may change from a slow tempo (for example a largo, to use classical music terminology) to a brisk tempo (for example, an allegro) in the some track.

[0062] In this case it is beneficial to insert a relative timebase indicator at the beginning of the change to the brisk tempo to adapt the timebase to the time values to be coded.

Claims

1. A method of storing data in a multimedia file containing on absolute timebase indicator and at least one track in which said data is stored, said data including time values, and said method being characterized in that each track is associated with at least one relative timebase indicator, as a function of said absolute timebase, and in that some or all time values contained in a track are determined relative to a relative timebase indicator associated with said track.

2. A method according to claim 1, wherein each relative timebase indicator is stored in the track with which it is associated.

3. A method according to either claim 1 or claim 2, wherein each of said tracks is dedicated to a single type of data.

4. A method according to any preceding claim, wherein each relative timebase indicator is defined as the highest common factor of the time values contained in the track with which it is associated.

5. A method according to any of claims 1 to 3, wherein a plurality of relative timebase indicators are associated with the same track and each of said relative timebase indicators is associated uniquely with a portion of said track.

6. A method according to the preceding claim, wherein each relative timebase indicator is defined as the highest common factor of the time values contained in the portion with which it is associated.

7. A method according to either claim 5 or claim 6, wherein each time value is defined relative to the relative timebase indicator that precedes it in the track containing it.