Understanding the HOTDOG files on DVD of California electronics

[woid]

I have no experiencs with kar-files and soft-player so I didnt fully understand what you mean by synced with note...

I think that 3rd and 4th byte of mask2 should be 0. The reason is that all timecodes (except the special code 0) are in increasing order. If 3rd or 4th byte of mask2 is not 0 the timecodes would not be in increasing order anymore...

[bigboss97]

When you create a KAR-file with a MIDI and a text file you have to select the melody track (channel). Then the tool (e.g. karakan) will split the text (lyrics) based on its vocal and assign the timecode of notes to the text elements. Therefor the lyrics' timecode matches the music timecode exactly. Since the singer needs a reaction time to read the text a delay is added by the player.

When I was decoding the timecode I noticed that the lyric is not matching the note. I don't think the delay is already coded in the song.

You might be able to write a routine to adjust the time code. You can see when the note is played (in dvd2midi):
        if( !(C2& 0x80))   // Play note
        {       EvtSerie[Cnt].Chn|= 0x90;


Until now, I always find the melody in channel 0x00. Therefor if you can search for:
   EvtSerie[Cnt].Chn= 0x90; // and
   EvtSerie[Cnt].Velo!= 0;   // because 0x00 means turn off the note

You should be able to find the lyric very close to the note after qsort().

HTH
Phuoc Can HUA

woid wrote

I have no experiencs with kar-files and soft-player so I didnt fully understand what you mean by synced with note...

[woid]

Thank you for the expaination. But I am still dont understand the outcome of my previous experiment. How can the tempo of the music change when I change the timecodes of the lyrics?
I will have to do some more experiments this weekend to understand more.

I have been looking at the code in hd00Midi.cpp and look at the timecodes for channel 0.
I found some bugs/issues in hd00midi.cpp:

1)
FindLyrStart() does not work for the song I tried (3df4 "Moon shadow").
I think it is better to seach for timcode != 0 to find the start of lyrics instead of 3 consecutive "0d 0a".
Would this work for your chinese songs?
//fseek( InFile, 2, SEEK_CUR);
//  for( int I= 0; I< 3 && Ret; I++)
//  {       while( Ret)
//          {       Ret= fread( Buf, 1,4, InFile);
//                  printf("FindLyrStart: %x %x\n", Buf[0],Buf[1]);
//                  if( Buf[0]== 0x0d && Buf[1]== 0x0a)
//                          break;
//          }
//  }
fseek( InFile, 3, SEEK_CUR);
while( Ret)
{
  Ret= fread( Buf, 1,4, InFile);
  printf("FindLyrStart2: %x %x %x %x\n", Buf[0],Buf[1], Buf[2], Buf[3]);
  if( Buf[2]!=0 || Buf[3]!=0)
    break;
}
fseek( InFile, -4, SEEK_CUR);


2) There seems to be some endian issues in hd00Midi.cpp. I sometimes use a sparc station so I would like if we could make the code "endian-safe" even if it is just a hack so far.
E.g:
        //fread( &EvtSerie[Cnt].Time,1,2, lFile);
        unsigned char t1, t2;
        fread( &t1,1,1, lFile);
        fread( &t2,1,1, lFile);
        EvtSerie[Cnt].Time = (t2 << 8) | t1;

[bigboss97]

In the TXT-file all words are printed in one single line. But when I checked the MIDI file with a player the lyric is fine, except that many lines consist only one word. But this is the data in the LPD-file. So, that's correct.

The problem is in mapLyric() and it's using a different way to find the lyric start.
Obviously, the current FindLyrStart() (with 3x 0x0d 0x0a) is working fine (at least for Moon Shadow)  

woid wrote

1)
FindLyrStart() does not work for the song I tried (3df4 "Moon shadow").
I think it is better to seach for timcode != 0 to find the start of lyrics instead of 3 consecutive "0d 0a".
Would this work for your chinese songs?
//fseek( InFile, 2, SEEK_CUR);
//  for( int I= 0; I< 3 && Ret; I++)
//  {       while( Ret)
//          {       Ret= fread( Buf, 1,4, InFile);
//                  printf("FindLyrStart: %x %x\n", Buf[0],Buf[1]);
//                  if( Buf[0]== 0x0d && Buf[1]== 0x0a)
//                          break;
//          }
//  }

[woid]

Ok, maybe there is some other problem with FindLyrStart(). Your version of FindLyrStart() does not work for me on "Moon Shadow" on a sparc station. Maybe it is an other endian issue. I will try it when I get home on an Intel PC.

The midi files created on sparc are also corrupt and I suspect that it is because of endian issues...

[bigboss97]

I had a look in your problem again. But I still have no proper explaination  
1) As you said, it could be the countdown.
2) No explaination, I just haven't found a way to "link" two lots of information which makes the music slow down and lyrics remain the speed.
The lyric timecode is absolute. If it's increased it should not change any speed, unless it's delta-timecode, that's in the case of MIDI.

In my MIDI routine, you can see all unprocessed MIDI events on the screen as known events. But if valid MIDI events are used for the synchronization you won't see them. But... you can use GN-MIDI tools (freeware) to make the MIDI file readable. You may find more information then.

Btw, now I'm still trying to find a way to create my own (mixed-mode) DVD.  Then we can modify the data files easily. So, we should be able to add our own songs. Then it should be easier to analyse the problem. PgcEdit sounds promising. But still haven't found the way to do what I want.

bB

woid wrote

The first attempt was to substract the delay (timecode) of the first character from all timecodes in the lyrics. My hope was that the lyrics would also start immediatly and in sync with the music.
Unfortunately the result was same as before. The lyrics was still delayed about 5 seconds.
$ ./adjustTiming 3d_f4.lpd -337

Then I made a second experiment. I tired to add the delay of the first character to the timecodes. My theory was that this would double the delay to about 10 seconds. When I did this something strange happend. The tempo of the music was changed to very very slow. The lyrics continued in the original tempo until the middle of the song where the lyrics stopped. The music continued in the same very slow pace.
$ ./adjustTiming 3d_f4.lpd 338

I am confused about this result. It seems to be some dependacy between the lyrics part and the midi part. Maybe there are some syncronisation events embedded in the midi stream? Have you found any strange events in the midistream that could be syncronisation events?

[scieman]

Sir, please post some link on where can i download the HOTDOG20.dat file or maybe upload it so i can download and try to use your greatfull work.

[bigboss97]

From time o time I've seen hotdog00.zip in eMule network. You might want to try your luck. Be patient and do not give up.

good luck

scieman wrote

Sir, please post some link on where can i download the HOTDOG20.dat file or maybe upload it so i can download and try to use your greatfull work.

[bigboss97]

I've also found (with soft-player) BLUE SUEDE SHOES is out of sync. This song starts straight with lyrics as well. Will try to debug the midi later.

woid wrote

I have made some experiments with "adjustTiming" on song 3df4 ("Moon shadow") and the result is very confusing. The lyrics on "Moon shadow" is delayed about 5 seconds (timecode of first character: 0x152=338). The music starts immediatly, but the lyrics starts about 5 seconds later.

[bigboss97]

This is not the best solution, but the easiest one. Instead of patching the (absolute) time code in lyrics, I patched the MIDI (delta) time code, see below:

That also means instead of letting the lyrics start earlier, we let the MIDI start later. There will be a silent phase in the begining. But as least we can sing now  
You can try this on the hard-player.

[woid]

Good! Very good that you found a workaround. It seems to be many songs with the same problem with delay. Can you explain what you did?

[woid]

Now I have tried to reproduce you patch on "blue suede shoes". My attempt failed however. When I play the patched dvd, the song hangs after a few words. I have to push the powerswitch on the frontpanel to recover.
I guess the patch is in the begining of the midipart. I used the utils posted in this forum before and I patched the .mpd file. The first "7F" I patched is on offset 0x12 in the .mpd file. Is this correct?  

[bigboss97]

I just checked my .mpd offset 0x12 seems to be correct.
Before it crashed did the music start with delay and in sync with lyrics? Did everything (music and lyric) stop?
What would happen if you run dvd2midi on the patched DVD and use a soft-player to play the MIDI file?
What you can try is to move the delays (4x time codes 0x7f) to a later spot. Since they are delta time codes you can place them anywhere before the first note.

woid wrote

Now I have tried to reproduce you patch on "blue suede shoes". My attempt failed however. When I play the patched dvd, the song hangs after a few words. I have to push the powerswitch on the frontpanel to recover.
I guess the patch is in the begining of the midipart. I used the utils posted in this forum before and I patched the .mpd file. The first "7F" I patched is on offset 0x12 in the .mpd file. Is this correct?  

[woid]

The music started and seemed to be in sync with the lyrics. On the second screen of lyrics everything froze (one the word "the").
I only have the iso file left so I havent been able to run dvd2midi again.
Where can I put the "0x7f"s?    

[bigboss97]

Have you got a virtual CD software which can mount the ISO-image?

At the moment, I don't have access to all the tools. But when I look into my original post it seems to be incorrect. The patch should go into the 1st byte of the time codes, in order to delay of the music, see:
http://board.midibuddy.net/showpost.php?p=533722&postcount=31

In the hex-dump, it looks like patching the 2nd byte (not very sure). Try to run dvd2midi and turn on the midi-log. Make sure it's patching the 1st byte of the time code. I'll double check that tonight.

Basically, you can patch a delay on any MIDI event because it's a delta value. Of course, this has to happen before any note. Otherwise the music will sound "broken". At the beginning, you will find both time code bytes equal 0. If you patch on one of those events you are safe.

woid wrote

I only have the iso file left so I havent been able to run dvd2midi again.
Where can I put the "0x7f"s?    

[bigboss97]

I just double checked. Based on the MIDI-log, the 0x7f are in the first time code byte.
00 01 *10* 41 00  Unknown
00 01 *10* 41 00  Unknown
00 01 *10* 41 00  Unknown
007f  7f 01[b0]79 00
00fe  7f 01[b1]79 00
017d  7f 01[b2]79 00
01fc  7f 01[b3]79 00
01fc  00 01[b4]79 00
01fc  00 01[b6]79 00
01fc  00 01[b9]79 00

Then I really can't explain why it's frozen. The first 3 events are those which I can't interpret. Maybe they are causing trouble. What you can try is to move the 0x7f to some later events.

[woid]

I managed to find the fault. There was a bug in the updateDvd.cpp file (the implementation of fseek() in cygwin for XP doesnt seem to work very well on large files (larger than 0x80000000). I changed fseek() to fseeko() and now it works much better compiled with cygwin for XP). The bug made the updated song in the dvd iso-file corrupt. I will soon post an updated version of updateDvd.cpp.

With the corrected version of updateDvd both methods of synchronizing lyrics with midi seem to work. I tried to add a delay in the midi part of "Blue suede shoes" as suggest by bigboss97 and it worked. I also tried my method of substracting an offset to all timecode in the lyrics part of "Moon shadow" as suggested before. It also worked. Conclusion: We now have two methods of synchronizing lyrics with midi.

[woid]

Updates of updateDvd. The program will seach a dvd image file for the pattern of a song and replace the song in the dvd image with a new version of the song.

Updates:
* The program had a serious bug that made the new song on the dvd image corrupt (atleast when the program was compiled with cygwin for XP). The attached version solves the problem.

* Also a optional parameter was added so that it is possible to specify a start offset to start the search from in the image file.

updateDvd.zip

[bigboss97]

Nice to see it working.
Can you branch this to a new thread as fixing lyric asynchrony and give a summery of the two methods. So, newcomers don't need to go through all existing discussions. We want people make the most out of this.

woid wrote

I managed to find the fault. There was a bug in the updateDvd.cpp file (the implementation of fseek() in cygwin for XP doesnt seem to work very well on large files (larger than 0x80000000). I changed fseek() to fseeko() and now it works much better compiled with cygwin for XP). The bug made the updated song in the dvd iso-file corrupt. I will soon post an updated version of updateDvd.cpp.

With the corrected version of updateDvd both methods of synchronizing lyrics with midi seem to work. I tried to add a delay in the midi part of "Blue suede shoes" as suggest by bigboss97 and it worked. I also tried my method of substracting an offset to all timecode in the lyrics part of "Moon shadow" as suggested before. It also worked. Conclusion: We now have two methods of synchronizing lyrics with midi.

[lala]

I got karaoke DVD of California electronic, my friend got the vcd of California electronic (nhac 5 so).  It has alot of good song on that version like "nhac tien chien".  I tried to play vcd on my dvd player but it didn't work. Is it possible to extract all the midi file of the vcd and add to dvd? Thanks