1,701

F1ReB4LL wrote:

http://forum.redump.org/topic/20666/seg … -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

========== 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.

1,702

F1ReB4LL wrote:

So, there's a common bug in C2 errors detection? Some of the other cases were mentioned here: http://forum.redump.org/topic/18736/jac … re-adding/

same.
http://forum.redump.org/post/65033/#p65033
http://forum.redump.org/post/65045/#p65045

Btw, wrong offset of VideoNow disc was solved?

1,703 (edited by claunia 2019-02-01 00:50:29)

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.

1,704

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.

1,705

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.

1,706

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)

1,707

http://forum.redump.org/topic/18552/meg … e-kingpin/ -- DIC dumps one of the audio tracks wrong, another cache issue? hmm

Post's attachments

MEGADRIVE.7z 2.79 mb, 15 downloads since 2019-02-02 

You don't have the permssions to download the attachments of this post.

1,708

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.

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?

1,709

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:

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:


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.

1,710

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

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

1,711

iR0b0t wrote:

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

I know. The point is that dumps with SecuROM are supposed to be listed with a single error. Currently, EdcEcc isn't displaying that error.

1,712

ajshell1 wrote:

SecuROM are supposed to be listed with a single error

We changed it, its in the backlog in this topic.

PX-760A (+30), PX-W4824TA (+98), GSA-H42L (+667), GDR-8164B (+102), SH-D162D (+6), SOHD-167T (+12)

1,713

It seems Monsters, Inc. Scream Team Training is SecuROM. Is Monsters, Inc: Scare Island SecuROM? I saw this pattern for the first time.

1,714 (edited by nightson 2019-02-07 03:46:09)

Hey sarami,

I tried to dump the Chinese release of Kyrandia III. Everything went well but DIC outputted the (Subs indexes) files along with the normal files. What's weird is that the hashes of the (Subs indexes).bin and (Subs indexes).cue match the normal ones. DIC found no C2 errors but CDmage reports 2 errors at the very end. I tried to dump it with two drives (PX-760 and PX-755) at both 4X and 8X but got the same result. I also tried to dump the CD with IsoBuster but encountered an error at the very end and ended up with a corrupt image. The CD itself is scratch free,  be the way.

Any idea what caused the problem?

Logs:
https://www38.zippyshare.com/v/JpNEaYqx/file.html

Post's attachments

1.jpg 104.46 kb, 12 downloads since 2019-02-07 

You don't have the permssions to download the attachments of this post.

1,715 (edited by sarami 2019-02-07 06:53:02)

nightson wrote:

Any idea what caused the problem?

Try the latest test version and re-report.
http://www.mediafire.com/file/eq80y20l9 … st.7z/file

nightson wrote:

DIC found no C2 errors but CDmage reports 2 errors at the very end.

Perhaps, last 2 sectors are mastering error.

nightson wrote:

I tried to dump it with two drives (PX-760 and PX-755) at both 4X and 8X but got the same result.

Try 12x, 16x, 20x, 24x, 28x, 32x, 40x and 48x. Low-speed is not always good.

1,716

sarami wrote:
nightson wrote:

Any idea what caused the problem?

Try the latest test version and re-report.
http://www.mediafire.com/file/eq80y20l9 … st.7z/file

nightson wrote:

DIC found no C2 errors but CDmage reports 2 errors at the very end.

Perhaps, last 2 sectors are mastering error.

nightson wrote:

I tried to dump it with two drives (PX-760 and PX-755) at both 4X and 8X but got the same result.

Try 12x, 16x, 20x, 24x, 28x, 32x, 40x and 48x. Low-speed is not always good.

Tried 12x, 24x and 48x with the 20181022 release. The results are exactly the same.

The test version didn't output the  (Subs indexes) files but the bin file has the same hash as before.
Can we safely say it's mastering error?

1,717

nightson wrote:

The test version didn't output the  (Subs indexes) files but the bin file has the same hash as before.

Logs and bin of last 2 sectors and scm of last 2 sectors, please.

1,718 (edited by nightson 2019-02-07 12:50:32)

sarami wrote:
nightson wrote:

The test version didn't output the  (Subs indexes) files but the bin file has the same hash as before.

Logs and bin of last 2 sectors and scm of last 2 sectors, please.

Logs: https://www76.zippyshare.com/v/jimIUXBM/file.html

Post's attachments

KYRANDIA_III_Last_2_Sectors.bin 4.59 kb, 16 downloads since 2019-02-07 

KYRANDIA_III_Last_2_Sectors.scm 4.59 kb, 14 downloads since 2019-02-07 

You don't have the permssions to download the attachments of this post.

1,719

Thanks.

LBA[291609, 0x47319], MSF[64:50:09], mode 1
LBA[291461, 0x47285], MSF[64:48:11], mode 1

291610 is missing. This is a bug of EccEdc.exe. I'll fix it.
Last sector is correct as ecc/edc, but MSF is incorrect. I'll add this bad MSF as an error.

1,720

sarami wrote:

291610 is missing. This is a bug of EccEdc.exe. I'll fix it.
Last sector is correct as ecc/edc, but MSF is incorrect. I'll add this bad MSF as an error.

Test version
20190208 (Windows)
http://www.mediafire.com/file/eq80y20l9 … or_test.7z
20190208 (Linux)
http://www.mediafire.com/file/uw3e03kdk … x_test.tar

1,721

sarami wrote:
sarami wrote:

291610 is missing. This is a bug of EccEdc.exe. I'll fix it.
Last sector is correct as ecc/edc, but MSF is incorrect. I'll add this bad MSF as an error.

Test version
20190208 (Windows)
http://www.mediafire.com/file/eq80y20l9 … or_test.7z
20190208 (Linux)
http://www.mediafire.com/file/uw3e03kdk … x_test.tar

Tested working.

Here are the new logs: https://www18.zippyshare.com/v/rM1dACiJ/file.html

1,722 (edited by usurper 2019-02-09 13:57:10)

Sarami, there seems to be a problem with the latest version of DIC and Siedler, Die - Platin Editon I - II - III - IV (Germany) (Disc 2).
I have dumped my brand new copy of this disc and I got a different hash on Track 4 than Maki.
However Maki didn't got a C2 error on his dump. Please check attached logs of Maki and me.

Maki's Logfiles
usurper's Logfiles

1,723

nightson wrote:

Tested working.

Thanks tested.

LBA[291610, 0x4731a], MSF[64:50:10], mode 1 Invalid mode: [e1]
[ERROR] Number of sector(s) where bad MSF: 1
    Sector: 291611, 
[ERROR] Number of sector(s) where mode is invalid: 1
    Sector: 291610, 
Total errors: 2
Total warnings: 0

It worked as I intended.



usurper wrote:

I have dumped my brand new copy of this disc and I got a different hash on Track 4 than Maki.
However Maki didn't got a C2 error on his dump. Please check attached logs of Maki and me.

There is a same problem in your track 04. (subQ is all zero)

sarami wrote:
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.

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]
LBA[248743, 0x3cba7]: Track[04]: SubQ Reread [crc16 unmatch] -> NG. Fix manually
LBA[248743, 0x3cba7]: Track[04]: SubQ[12]:Adr[0] -> [0x01]
LBA[248743, 0x3cba7]: Track[04]: SubQ[13]:TrackNum[00] L:[781] -> [04], L:[688]
LBA[248743, 0x3cba7]: Track[04]: SubQ[14]:Idx[00] -> [01], L:[781]
LBA[248743, 0x3cba7]: Track[04]: SubQ[15-17]:PrevRel[1937, 00:25:62], Rel[0, 00:00:00] -> [1938, 00:25:63], L:[1047]
LBA[248743, 0x3cba7]: Track[04]: SubQ[19-21]:PrevAbs[248892, 55:18:42], Abs[0, 00:00:00] -> [248893, 55:18:43]
LBA[248743, 0x3cba7]: Track[04]: SubQ[22]:CrcHigh[0000] -> [0x8d]
LBA[248743, 0x3cba7]: Track[04]: SubQ[23]:CrcLow[0000] -> [0xc2]

Perhaps this problem occurs due to reread, so I'll abort the program not to create the bad dump in next test version if this problem occurs.

1,724

What does that mean? My disc is brand new!

1,725

edccchk and CDMage show 314 errors, DIC shows 313 errors, error count bug?

Post's attachments

badsectorscountbug.7z 244.67 kb, 16 downloads since 2019-02-10 

You don't have the permssions to download the attachments of this post.