Redump Forum

Posted: **Thu Jan 31, 2019 7:55 am**

F1ReB4LL wrote:/viewtopic.php?t=15978 … -shock-us/ -- disc 1 is dumped wrong.

subchannel of 1st sector is wrong.
_subError.txt

LBA[000000, 0000000]: Track[01]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
LBA[000000, 0000000]: Track[01]: SubQ[19-21]:PrevAbs[149, 00:01:74], Abs[149, 00:01:74] -> [150, 00:02:00]
LBA[000000, 0000000]: Track[01]: SubQ[22]:CrcHigh[0x04] -> [0x6f]
LBA[000000, 0000000]: Track[01]: SubQ[23]:CrcLow[0xa1] -> [0xe1]

_disc.txt

Code: Select all

========== LBA[000000, 0000000]: Sub Channel ==========
      +0 +1 +2 +3 +4 +5 +6 +7 +8 +9 +A +B
    P FF FF FF FF FF FF FF FF FF FF FF FF
    Q 41 01 01 00 00 00 00 00 03 00 28 32
    R 00 00 00 00 00 00 00 00 00 00 00 00
    S 00 00 00 00 00 00 00 00 01 00 00 00
    T 00 00 00 00 00 00 00 00 01 00 00 00
    U 00 00 00 00 00 00 00 00 01 00 00 00
    V 00 00 00 00 00 00 00 00 01 00 00 00
    W 00 00 00 00 00 00 00 00 01 00 00 00

Please try to redump it with different drive speed.

Posted: **Thu Jan 31, 2019 8:08 am**

F1ReB4LL wrote:So, there's a common bug in C2 errors detection? Some of the other cases were mentioned here: /viewtopic.php?t=14101 … re-adding/

same.
/viewtopic.php?p=24867#p24867
/viewtopic.php?p=24869#p24869

Btw, wrong offset of VideoNow disc was solved?

Posted: **Thu Jan 31, 2019 6:26 pm**

Hi sarami,

I want to decode the video frames to be 100% sure of how to offset VideoNow.
That will take at least the weekend.

I will maintain you posted.

Technicalities:

Between track 1 and track 2, in the interleaved audio, there's some digital data, whose function is as of now, unknown.
If we move the start of the first frame to 0, the frame that contains that digital data gets cut between track 1 and 2.
If we move the start of the first frame to 18032, the frame that contains that digital data is the first frame of track 2.

It is my understanding that all discs contain the same exact first track, showing the VideoNow logo.
Therefor I suppose that this track was premastered, with enough space at the start (hereby the 18032 bytes), to be 106 frames (if the first track contains less frames -that is, is less than 891 sectors-, the player rejects the disc), and the rest of the disc was appended to it.

What puzzles me is this digital data, so I want to check if it's the same in all discs and what video contains that data.
When I played the disc on the player, just after the VideoNow logo there was a kind of non-interactive menu of contents. I suspect this is the video I'll found there.

I had not time to check the other discs I have, will do tomorrow.

Posted: **Fri Feb 01, 2019 6:29 pm**

Hi,

I have not yet implemented the VideoNow Color (B&W is a completely different format) decoder, but I think it is not necessary anymore to decide the offset issue (still I will implement it as I find interesting to be able to have an uncompressed AVI of them).

Logic dictates that the engineers that made the format knew about read (and possibly also write) offset, and decided to put white space before the first frame to let the drive ample margin as to get the first frame without cuts.

Facts:

A frame needs 19600 bytes.
The player requires at least 106 frames at the start of a disc, or will reject it.
All known discs show the VideoNow Color logo at the start.
That means the first track will be 106 frames, or 2077600 bytes. Aligned to Compact Disc sectors, that's 891 sectors

So there is the choice of two way of correcting the write/read offsets:
Sarami's way: Align the first video frame to byte 0.
Claunia's way. Align the first video frame to the leftover space between 891 sectors and 106 frames, that is, 18032 bytes.

After testing with all the discs in redump's database, this is what I've found:
Using sarami's , 21 of 26 have the same hash (80%), the other 5 give 5 unique hashes.
Using claunia's, 26 of 26 have the same hash.

I think this is proof of my theory:
The first track, the logo, was used verbatim between discs, containing always the same amount of free space at the start to allow any drive mechanism to find the first frame complete. That first track consists of 18032 empty bytes followed by 106 frames.

Posted: **Fri Feb 01, 2019 8:29 pm**

As you say, it seems my VideoNow disc has the logo of 891 sectors.
And my app searches "81 E3 E3 C7 C7 81 81 E3".
https://imgur.com/bG2k7T1
Perhaps, each track of my disc starts from these bytes order.
I don't know if all VideoNow discs (VideoNow, VideoNow Color, VideoNow Jr., VideoNow XP) start from these bytes.

Posted: **Fri Feb 01, 2019 9:08 pm**

sarami wrote:As you say, it seems my VideoNow disc has the logo of 891 sectors.
And my app searches "81 E3 E3 C7 C7 81 81 E3".
https://imgur.com/bG2k7T1
Perhaps, each track of my disc starts from these bytes order.
I don't know if all VideoNow discs (VideoNow, VideoNow Color, VideoNow Jr., VideoNow XP) start from these bytes.

VideoNow is a completely different format. I shall receive 3 discs soon.
VideoNow Color and VideoNow Jr. are the same format, only difference is the materials that make the disc. Jr is flexible, for little children security.
As for VideoNow XP the only thing I know is that "their playability is restricted to pause and jump chapter", according to forums and other unofficial information. I have not been able to find a single disc, or dump. But seeing that the digital data in the audio interleaved bytes at the start of track 2 makes the Nickelodeon discs I have pause, but not the Star Wars discs, I'm inclined to think they use something similar. They can also have just put data interframe, as the Color discs show frames don't need to be continuous.

What still needs to be known is if the data is little endian or big endian.
Should it be "81 E3 E3 C7 C7 81 81 E3" or "E3 81 C7 E3 81 C7 E3 81".
I think it should be big engian (81E3E3C7...) as the audio is every 10 bytes, and in big endian, it starts at the 10th byte inside the frame. (If you are curious, the audio is 17640Hz, 2 channels, 8 bit per channel)

Posted: **Sat Feb 02, 2019 2:59 pm**

/viewtopic.php?t=13924 … e-kingpin/ -- DIC dumps one of the audio tracks wrong, another cache issue?

Posted: **Sun Feb 03, 2019 9:32 am**

claunia wrote:VideoNow is a completely different format. I shall receive 3 discs soon.
VideoNow Color and VideoNow Jr. are the same format, only difference is the materials that make the disc. Jr is flexible, for little children security.

Thanks info. I ordered Color, Jr, and XP by amazon.

F1ReB4LL wrote:DIC dumps one of the audio tracks wrong, another cache issue?

I'm not sure but I can only say that 202328 Q-channel is all zero. It's unusual.

Code: Select all

LBA[202328, 0x31658]: Track[10]: SubQ[12]:Adr[0] -> [0x01]
LBA[202328, 0x31658]: Track[10]: SubQ[13]:TrackNum[00] L:[781] -> [10], L:[688]
LBA[202328, 0x31658]: Track[10]: SubQ[14]:Idx[00] -> [01], L:[781]
LBA[202328, 0x31658]: Track[10]: SubQ[15-17]:PrevRel[14626, 03:15:01], Rel[0, 00:00:00] -> [14627, 03:15:02], L:[1047]
LBA[202328, 0x31658]: Track[10]: SubQ[19-21]:PrevAbs[202477, 44:59:52], Abs[0, 00:00:00] -> [202478, 44:59:53]
LBA[202328, 0x31658]: Track[10]: SubQ[22]:CrcHigh[0000] -> [0x5e]
LBA[202328, 0x31658]: Track[10]: SubQ[23]:CrcLow[0000] -> [0xcf]

Also I ordered this by amazon to test. Btw, can subdump dump this sector correctly without fixing?

Posted: **Sun Feb 03, 2019 7:39 pm**

Hey sarami. I think I found a bug with EdcEcc. Perhaps "oversight" is a better word than "bug":

My copy of Monsters, Inc: Scare Island produces this when dumped with DIC in the EdcEcc.txt file:

Code: Select all

LBA[233309, 0x38f5d], MSF[51:52:59], mode 2 form 1, SubHeader[1](IsInterleaved[00]), [2](ChannelNum[00]), [3](SubMode[00]), Form 1, [4](CodingInfo[00])
LBA[233310, 0x38f5e], MSF[51:52:60], mode 2 form 1, SubHeader[1](IsInterleaved[00]), [2](ChannelNum[00]), [3](SubMode[00]), Form 1, [4](CodingInfo[00])
LBA[233311, 0x38f5f], MSF[51:52:61], mode 2 form 1, SubHeader[1](IsInterleaved[00]), [2](ChannelNum[00]), [3](SubMode[00]), Form 1, [4](CodingInfo[00])
LBA[233312, 0x38f60], MSF[51:52:62], mode 1
LBA[233313, 0x38f61], MSF[51:52:63], mode 2 form 1, SubHeader[1](IsInterleaved[00]), [2](ChannelNum[00]), [3](SubMode[09]), Form 1, Data, End audio, [4](CodingInfo[00])
LBA[233314, 0x38f62], MSF[51:52:64], mode 2 form 1, SubHeader[1](IsInterleaved[00]), [2](ChannelNum[00]), [3](SubMode[00]), Form 1, [4](CodingInfo[00])
LBA[233315, 0x38f63], MSF[51:52:65], mode 2 form 1, SubHeader[1](IsInterleaved[00]), [2](ChannelNum[00]), [3](SubMode[00]), Form 1, [4](CodingInfo[00])
[NO ERROR] User data vs. ecc/edc match all

By way of comparison, here is my dump of Monsters, Inc. Scream Team Training:

Code: Select all

LBA[257659, 0x3ee7b], MSF[57:17:34], mode 2 form 1, SubHeader[1](IsInterleaved[00]), [2](ChannelNum[00]), [3](SubMode[09]), Form 1, Data, End audio, [4](CodingInfo[00])
LBA[257660, 0x3ee7c], MSF[57:17:35], mode 1
LBA[257661, 0x3ee7d], MSF[57:17:36], mode 1
LBA[257662, 0x3ee7e], MSF[57:17:37], mode 1
[ERROR] Number of sector(s) where mode is invalid: 1
    Sector: 257659, 
Total errors: 1
Total warnings: 0

Basically, it doesn't notice the Mode 1 sector since Scare Island is normally Mode 2.

Posted: **Sun Feb 03, 2019 8:24 pm**

@ajshell1 : It's intentional. It still remains a data sector, which can be mode 0, 1 or 2. All within a data track.

Redump Forum

DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator

Re: DiscImageCreator