More Re: its in the 3s.....

[willieb9000@y...]

OK, I have looked at the code for tyconvert again and I just cannot 
find where he skips the 01 and 02 blocks. My guess is that he does it 
by omission since all valid audio and video records contain 0C and 
0E, but don't anybody quote me becasue I have no idea. 
I have noticed though that in the valid video records, the first 
five bytes follow a pattern:

00 01 06 E0 30 
01 B2 42 E0 30 
00 00 4A E0 30 
03 CD C2 E0 30 
00 00 42 E0 30 
00 01 06 E0 30 
00 00 4B E0 30 
01 AD 42 E0 30 
00 00 42 E0 30

We know the first 3 bytes contain the size of the data the record 
refers to. the 4th one, E0, says the packet is video. The 5th seems 
to always be 30 though. 
In those unknown 03 packets, the first 4 bytes are always the same:

00 01 8E 03 
00 01 8E 03 
00 01 8E 03 
00 01 8E 03 
00 01 8E 03 
00 01 8E 03 

I can't tell how tyconvert parses the chunkk, but is it possible it 
reads the "E 03" in the unknown chunks as the "E0 3" in the valid 
video chunks and therefore includes them in the stream? These unknown 
records are in the record portion of the chunk, but apparently they 
do not correspond to actual packets in the rest of the chunk. Once 
tyconvert recognizes the record as valid, though, the data packet 
that tyconvert is expecting to correspond with that "record" is 
missing and then the next *valid* record gets mismatched with the 
packet after the one it really corresponds to, and therefore it 
doesn't match, etc. And tyconvert never recovers.

This is all purely speculation, but I am trying to narrow down the 
problem so that people who know what they are doing might be able to 
fix it with as little effort as possible.
Anyway, that is all I can come up with. It definitely has to be 
mistaking the record for a valid one though. If anyone could let me 
know if I am on to something, I'd appreciate it.