Multimedia 2.594 Themen, 14.639 Beiträge

MIDI .KAR Dateien: Timing Format der Lyric

Sigi Saudi / 5 Antworten / Flachansicht Nickles

Hallo Gem.einde,

Wi weitlaeufig bekannt, lebe ich in Thailand. Hier ist Karaoke, wie fast ueberall in Asien, ein grosses Thema. Deshalb befasse ich mich jetzt mit MIDI und .KAR Dateien, da hier eine sehr grosse Anzahl von Karaokesongs als .MID und als .KAR Dateien im Umlauf sind und hier die gaengigen Karaokeplayer dieses Format verarbeiten.

Ich habe mir die App Serenade v5.2 auf meinen Laptop heruntergeladen und fuege mit dieser App die Texte nun selbst in .MID Dateien ein. Um Korrekturen am Timing der Lyric  im Nachhinein vornehmen zu koennen, habe ich das Format der eingefuegten Lyric manuell zu dekodieren und zu verstehen versucht. Ich habe einen Hex Editor, der mich die Dateien im Hex/ASCII Format betrachten und editieren laesst. Hier ein Beispiel des Songs Goldfinger:


Track Identifier
4D 54 72 6B 00 00 05 E5 00       -->MTrk
Time Signature
FF 58 04 04 02 18 08 00             --> 4/4
Tempo
FF 51 03 09 27 C0 00
Sequence / Track Name
FF 03 24 50 31 30 30 31 38 2D 47 6F 6C 64 66 69 6E 67 65 72 2E ... -->Name of the file
                                                                                                      ... P10018-Goldfinger- ...
Tempo
FF 51 03 0B F9 CB 9E 1D
Lyric
FF 05 04 47 6F 6C 64 81 44         -->Gold
FF 05 03 66 69 6E 25                   -->fin
FF 05 05 67 65 72 2C 20 86 56    -->ger,_
FF 05 05 68 65 27 73 20 2B         -->he's_
FF 05 04 74 68 65 20 28              -->the_
FF 05 03 6D 61 6E 81 54             -->man
FF 05 05 2F 74 68 65 20 23         -->/the_
FF 05 04 6D 61 6E 20 58              -->man_
FF 05 05 77 69 74 68 20 32          -->with_
FF 05 04 74 68 65 29 57               -->the_
FF 05 02 6D 69 67                        -->mi
FF 05 04 64 61 73 20 3E              -->das_
FF 05 05 74 6F 75 63 68 85 4D    -->touch
FF 05 03 2F 41 20 5A                   -->/A_
FF 05 03 73 70 69 7A                   -->spi
FF 05 06 64 65 72 27 73 20 73    -->der's_
FF 05 05 74 6F 75 63 68 85 76    -->touch
FF 05 06 2F 53 75 63 6B 20 74    -->/such

... und so weiter ( _ steht hier fuer Space, Code 20)

Jede Lyriczeile beginnt mit der Markierung FF 05
FF markiert den Beginn eines Meta Events und 05 markiert eine Lyriczeile. Das naechste Byte enthaelt die Anzahl der Buchstaben und Zeichen der Lyric, die in diesem Metaevent abgelegt sind, in der ersten Zeile also 04 fuer den Text Gold, der 4 Buchstaben lang ist.

In der ersten Zeile und vor jedem Zeilenwechsel (Zeichen /) folgt nach dem Textfragment ein Timestamp (hier nach Gold 81 44, der in hexadezimaler Form den Einsatz des folgenden Zeilenbeginns markiert.

Die Kodierung dieser Bytes ist mir unklar. Ich weiss nur, wenn ich dort z. B. 83 44 eintrage, setzt die 2. Zeile spaeter ein.

Am Ende jeden Worts innerhalb einer Zeile steht ein Byte, das angibt, nach welcher Zeit das naechste Wort beginnt, aber die Kodierung dieses Bytes ist mir auch unklar. Ich weiss nur, dass ich mit diesem Byte den Zeitabstand zum naechsten Wort in der Zeile beeinflussen kann, aber groessere Werte ergeben nicht unbedingt groessere Abstaende und umgekehrt. 

Die 3. Zeile (ger,_) endet mit den Bytes 86 56. Normalerweise ist innerhalb einer Zeile nur ein Timing Byte am Ende eines Lyrics Fragments angehaengt. Was bedeutet das vorletzte Byte 86 in der Zeile?

Auch weiss ich nicht, wo das Timing fuer den generellen Beginn der Lyric gespeichert ist. Das Timing innerhalb der Lyric beginnt erst vor der zweiten Zeile, aber irgendwo muss ja auch der Beginn der ersten Zeile festgelegt sein.

Ich hoffe sehr, dass ihr mir weiterhelfen koennt!

Herzliche Gruesse aus Thailand, wo zum Glueck schon sporadisch die Regenzeit eingesetzt hat.

Sigi Saudi

Gruesse aus Wang Nam Kiaw / Thailand
bei Antwort benachrichtigen
Andreas42 Sigi Saudi „Hallo Andreas, Danke fuer deine Antwort. Mir ist klar, dass meine Fragestellung sehr speziell ist, aber man soll die ...“
Optionen

Hi!

Der Link ist gut, ich denke, da ist beschreiben, wie das zusammen hängt:

The actual data within an MTrk chunk takes the following form :

delta-time a variable length quantity, (1 to 4 bytes) denoting the time since the previous event.
event 2 or more bytes describing the event, of which there are three main types : MIDI, SysEx and Meta.

Wir haben das bisher vertauscht: die Zusatzbytes gehören nicht ans Ende der Meta-Zeile, sondern jeweils vor die nächste. Das ist eine Zeitinfo. Ich würde sagen die legt fest, wie lange die nächste Silbe blau markiert wird.

Das ist eine diese Delta-Timesangaben. leider ist das kein "im Klartext" lesbarer Wert, weil die zur Speicherplatzvermeidung speziell kodiert sind.

Here are some examples of numbers represented as variable-length quantities :

Value (hex) Representation (hex)
00000000 00
00000040 40
0000007F 7F
00000080 81 00
00002000 C0 00
00003FFF FF 7F
00004000 81 80 00
00100000 C0 80 00
001FFFFF FF FF 7F
00200000 81 80 80 00
08000000 C0 80 80 00
0FFFFFFF FF FF FF 7F

Most of the time, musical events are sufficiently close together that the delta-time can be expressed in a single byte (i.e. for delta-times of 0 - 127). When a larger delta-time needs to be specified then additional bytes are used. This provides an efficient way of storing delta-time values.

OK, mal schauen:

9E 1D
FF 05 04 47 6F 6C 64         -->Gold
81 44 
FF 05 03 66 69 6E               -->fin
25
FF 05 05 67 65 72 2C 20     -->ger,_
86 56
FF 05 05 68 65 27 73 20      -->he's_
2B
FF 05 04 74 68 65 20           -->the_
28 
FF 05 03 6D 61 6E               -->man

Das Problem ist jetzt, dass das nicht nur längenkodierte Werte sind, sondern auch noch Deltawerte bezogen auf den Grundtakt (oder wie man das auch immer nennt).

Only the bottom 7 bits of each of these bytes contributes towards the delta-time, the top bit being used to indicate (when it is set) that another byte follows, i.e. bit 7 of each byte is used to indicate continuation or end of the delta-time data. Consequently the last byte of any delta-time value will have its top bit clear.

Die Umrechnung kann ich auch nur auf Papier, dass geht im Kopf nicht mehr, weil man Binär shiften muss. Ok, mal schauen, nehmen wir den ersten "Wert": 9E 1D

Zuerst binär:

1001 1110 - 0001 1101

Das linke Bit im Byte gibt an, ob noch ein Byte folgt. Hier folgt also 1 Byte. In dem ist das Bit 0, also folgt kein weiteres. Zum Umrechnen muss man nun die 7 Bits der Bytes zusammenschieben:

0000 1111 - 0001 1101

Ergebnis:

0F - 1D = 3869 (dezimal)

Das ist nicht ganz einfach.

Bis dann
Andreas

Bitte bei der Ueberweisung im Betreff "Loeschen fuer Kohle" und den Beitrag angeben. Knausern hilft nicht!
bei Antwort benachrichtigen