2,001 (edited by user7 2019-08-01 19:29:28)

Dumped with /sf /nq /c2 twice each on my 760SA and 708

All four dumps "no unintentional c2 errors", none of the hashes matched either...

Disc is scratchless. (Its an action replay ps2 disc)

logs: https://drive.google.com/drive/folders/ … sp=sharing

All my posts and submission data are released into Public Domain / CC0.

2,002

Sarami, would it be possible for dic to auto-detect multisessional discs and use "/ms" automatically?

Thanks again for your amazing work, its very cool to see multisessional discs correctly represented in redump smile

All my posts and submission data are released into Public Domain / CC0.

2,003

F1ReB4LL wrote:

Any info on this? Can DIC detect the needed amount of empty sectors for the first track? As I understand, you need to align the 2nd track to start with the proper byte sequence, not the 1st track. If you detect the offset for the 2nd track, all the other tracks should also have the proper offset, including the 1st track.

Did you try this?

sarami wrote:

I created PVDTools(https://github.com/saramibreak/PVDTools) to decode VideoNow disc.
Please decode your VideoNow disc, using this tool.

sarami wrote:

If /vn 18032 is set, wav file isn't decoded properly and the last frame of previous track appears to the 1st frame of current track.


user7 wrote:

Dumped with /sf /nq /c2 twice each on my 760SA and 708

All four dumps "no unintentional c2 errors", none of the hashes matched either...

It seems 708 is good.

user7 wrote:

would it be possible for dic to auto-detect multisessional discs and use "/ms" automatically?

Uploaded.
http://www.mediafire.com/file/eq80y20l9 … st.7z/file
http://www.mediafire.com/file/uw3e03kdk … ar.gz/file

- added: using "/ms" automatically
- added: /aj flag (detecting Atari Jaguar CD header)

2,004 (edited by user7 2019-08-03 16:15:39)

sarami wrote:
user7 wrote:

Dumped with /sf /nq /c2 twice each on my 760SA and 708

All four dumps "no unintentional c2 errors", none of the hashes matched either...

It seems 708 is good.

The two 708 dumps don't match hashes hmm

All my posts and submission data are released into Public Domain / CC0.

2,005

Why was the track type set to audio in the cue?

Post's attachments

MUTANOID_MATH_VIS.zip 288.76 kb, 15 downloads since 2019-08-03 

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

2,006

I have an unlicensed Mini-CD that has a full-size-CD TOC. Is there anyway to tell DIC to just dump the maximimum mini-CD TOC length, instead of trying to dump the part of the disc that doesn't exist?

All my posts and submission data are released into Public Domain / CC0.

2,007

user7 wrote:

The two 708 dumps don't match hashes

F1ReB4LL wrote:

Why was the track type set to audio in the cue?

Uploaded: http://www.mediafire.com/file/eq80y20l9 … st.7z/file
- fixed: bad SubQ ctl is fixed when /nq is used
- fixed: 2 sectors are read when gets the mode of main-channel

========== LBA[000000, 0x00001]: Main Channel ==========
     :
     :
0910 : F8 AC D8 1C 5A 89 FB 26  C3 5A D1 FB 1C 43 49 F1   ....Z..&.Z...CI.
0920 : F6 C4 26 43 42 5F B5 24  00 FF FF FF FF FF FF FF   ..&CB_.$........
========== LBA[000001, 0x00001]: Main Channel ==========
       +0 +1 +2 +3 +4 +5 +6 +7  +8 +9 +A +B +C +D +E +F
0000 : FF FF FF 00 01 81 70 61  00 28 00 1E 80 08 60 06   ......pa.(....`.
0010 : A8 02 FE 81 80 60 60 28  28 1E 9E 88 68 66 AE AA   .....``((...hf..

2,008

Sarami, so far so good. I dumped two variants on GTA Vice City, the subindexes in the cue do not match:
https://drive.google.com/file/d/1BULb9E … sp=sharing
https://drive.google.com/file/d/13IReoY … sp=sharing

All my posts and submission data are released into Public Domain / CC0.

2,009

Uploaded: http://www.mediafire.com/file/eq80y20l9 … st.7z/file
If crc16 of subQ is 0, app do not return FALSE.

Try not to use /nq.

2,010

Thanks for the sub channel crc fix.

Any progress on backwards dumping?

Plextor PX-760A 1.07 (+30) : Plextor PX-716SA 1.11 (+30) : Plextor PX-W5224A 1.04 (+30) : Plextor PX-W4824 1.07 (+30) : Plextor PX-W4012TA 1.07 (+98) : Plextor PX-W1610TA (+99) : Plextor PX-W1210TA 1.10 (+99) : Lite-On LTR-48246S (+6) : Lite-On LTR-52246S (+6) : Lite-On LH-20A1H LL0DN (+6) : BenQ DW1655 BCIB (+618) : ASUS DRW-2014L1 1.02 (+6) : Yamaha CRW-F1 (+733) : Optiarc SA-7290H5 1H44 (+48) : ASUS BW-16D1HT 3.02 (+6)

2,011 (edited by xTMODx 2019-08-04 20:24:48)

Hi sarami, i have problem with an audio cd, DIC crash at the end... i can't mount the dump, it looks like the cue file is broken because of CDTEXT. here the logs https://www.mediafire.com/file/tbzmj99q … ue.7z/file

Edit: updated link

2,012

sarami wrote:

If /vn 18032 is set, wav file isn't decoded properly and the last frame of previous track appears to the 1st frame of current track.

Maybe you're decoding it wrong? The frame is exactly 19600 bytes and the 1st track should contain exactly 106 frames. But it always has the 2095632 size (for the Color discs), so, if you start with the non-zero byte, you will have an incomplete frame at the end? 106x19600 bytes + 18032 (incomplete frame) at the end? And the 2nd track will have 1568 bytes from that frame?

Look at these 2 tracks. It's a Color disc, it was dumped with /vn, the 1st track starts with the non-zero byte and your PVDTools.exe decodes 106 frames there. But the 2nd track doesn't start with 0x81, 0xe3, 0xe3, 0xc7, 0xc7, 0x81, 0x81, 0xe3. So the 1st track can't start with the non-empty byte here. But if you redump it as /vn 18032, the 2nd track starts properly.

Post's attachments

andy.7z 3.41 mb, 16 downloads since 2019-08-04 

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

2,013

Nexy wrote:

Thanks for the sub channel crc fix.

But this problem (http://forum.redump.org/topic/18552/meg … e-kingpin/) occurs again.

Nexy wrote:

Any progress on backwards dumping?

In the near future.

xTMODx wrote:

it looks like the cue file is broken because of CDTEXT

Perhaps, it needs unicode. I'll support it.

F1ReB4LL wrote:

Maybe you're decoding it wrong?

My color disc has 106x19600 bytes + 18032 (incomplete frame) in track 01. So, /vn 0 is no problem.
Your color disc has 106x19600 bytes + 7624 (incomplete frame) in track 01. So, you need to use /vn 10408. (18032 - 7624 = 10408)

Incomplete frame is VideoNow logo. This belongs to track 01, not track 02.

2,014

sarami wrote:

Your color disc has 106x19600 bytes + 7624 (incomplete frame) in track 01. So, you need to use /vn 10408. (18032 - 7624 = 10408)

Can you make a real autodetection of the offset? Users don't want to count those values, it should be automatical.

2,015

If the problem is occurring on a burned CD-R then the problem is likely the disc, pressed discs should not have random data. Probably better to add a switch for the special case.

Are you fixing also P and R-W channels for data/audio discs as well as the Q channel?

Daemon Tools is making working dumps of Tages (DVD and CD) I found after I bought it, but the images are encrypted (not nice of them), so will have to try to reverse engineer this. Hopefully we can find out how they are special and they can be dumped correctly.

Plextor PX-760A 1.07 (+30) : Plextor PX-716SA 1.11 (+30) : Plextor PX-W5224A 1.04 (+30) : Plextor PX-W4824 1.07 (+30) : Plextor PX-W4012TA 1.07 (+98) : Plextor PX-W1610TA (+99) : Plextor PX-W1210TA 1.10 (+99) : Lite-On LTR-48246S (+6) : Lite-On LTR-52246S (+6) : Lite-On LH-20A1H LL0DN (+6) : BenQ DW1655 BCIB (+618) : ASUS DRW-2014L1 1.02 (+6) : Yamaha CRW-F1 (+733) : Optiarc SA-7290H5 1H44 (+48) : ASUS BW-16D1HT 3.02 (+6)

2,016

sarami wrote:

If /vn 18032 is set, wav file isn't decoded properly and the last frame of previous track appears to the 1st frame of current track.

Have you seen the claunia's decoder? https://github.com/discimagechef/DiscImageChef.VideoNow
She says the frames are solid and shouldn't be split between tracks.

2,017 (edited by sarami 2019-08-06 12:31:38)

F1ReB4LL wrote:

She says the frames are solid and shouldn't be split between tracks.

Does it mean incomplete frame belong track 02, not track 01?

F1ReB4LL wrote:

But if you redump it as /vn 18032, the 2nd track starts properly.

How about the 3rd, 4th, 5th... tracks? Do these tracks really start with 0x81, 0xe3, 0xe3, 0xc7, 0xc7, 0x81, 0x81, 0xe3?

And please try to use /vn 10408 by your disc, then check if all tracks start with 0x81, 0xe3, 0xe3, 0xc7, 0xc7, 0x81, 0x81, 0xe3 except the last track.

2,018

sarami wrote:

Does it mean incomplete frame belong track 02, not track 01?

I've thought there shouldn't be any incomplete frames, only the possible empty sectors before the data for the first track and after the data for the last track? How can you work with an incomplete frame? Don't you lose the data when a part of the frame belongs to the track 1 and another part to the track 2? Don't you need to choose the proper offset to not to split the frames?

sarami wrote:

And please try to use /vn 10408 by your disc, then check if all tracks start with 0x81, 0xe3, 0xe3, 0xc7, 0xc7, 0x81, 0x81, 0xe3 except the last track.

Hmm, yes, with 10408 they do.

2,019

Sarami would you mind taking a look at this dump please? https://drive.google.com/file/d/1hYipVH … sp=sharing

Its "DVD Region X" a datel disc. It is similar to the ones that DO dump good in that all the errors are at the start of the disc, however dic doesn't flag them as intentional, and dic tries and fails to reread them.

All my posts and submission data are released into Public Domain / CC0.

2,020 (edited by Nexy 2019-08-07 05:18:59)

Could you also make it so it doesn't abort on C2 errors or a switch for it, sectors may be correctable with ECC.

Plextor PX-760A 1.07 (+30) : Plextor PX-716SA 1.11 (+30) : Plextor PX-W5224A 1.04 (+30) : Plextor PX-W4824 1.07 (+30) : Plextor PX-W4012TA 1.07 (+98) : Plextor PX-W1610TA (+99) : Plextor PX-W1210TA 1.10 (+99) : Lite-On LTR-48246S (+6) : Lite-On LTR-52246S (+6) : Lite-On LH-20A1H LL0DN (+6) : BenQ DW1655 BCIB (+618) : ASUS DRW-2014L1 1.02 (+6) : Yamaha CRW-F1 (+733) : Optiarc SA-7290H5 1H44 (+48) : ASUS BW-16D1HT 3.02 (+6)

2,021

F1ReB4LL wrote:

Can you make a real autodetection of the offset? Users don't want to count those values, it should be automatical.

Uploaded. http://www.mediafire.com/file/eq80y20l9 … st.7z/file
- added: /vnc flag for VideoNow Color

user7 wrote:

Its "DVD Region X" a datel disc.

Intentional c2 errors start from 25 and end to 4270. This disc has two protected files (BIG.DAT and DATA.DAT).

              Length of Directory Record: 56
        Extended Attribute Record Length: 0
                      Location of Extent: 2465
                             Data Length: 20000000
                 Recording Date and Time: 2000-12-20 10:34:06 +00:00
                              File Flags: 0 (Visible, File, Disassociated, File hasn't record format,Owner/Group ID hasn't,Final Directory Record)
                          File Unit Size: 0
                     Interleave Gap Size: 0
                  Volume Sequence Number: 1
               Length of File Identifier: 9
                         File Identifier: BIG.DAT;1

              Length of Directory Record: 58
        Extended Attribute Record Length: 0
                      Location of Extent: 23
                             Data Length: 5000000
                 Recording Date and Time: 2000-06-30 21:55:02 +00:00
                              File Flags: 0 (Visible, File, Disassociated, File hasn't record format,Owner/Group ID hasn't,Final Directory Record)
                          File Unit Size: 0
                     Interleave Gap Size: 0
                  Volume Sequence Number: 1
               Length of File Identifier: 10
                         File Identifier: DATA.DAT;1

2,022

Anything that can be done about it? Maybe modify DIC to handle data.dat like big.dat?

Thanks.

All my posts and submission data are released into Public Domain / CC0.

2,023

sarami wrote:

How about the 3rd, 4th, 5th... tracks? Do these tracks really start with 0x81, 0xe3, 0xe3, 0xc7, 0xc7, 0x81, 0x81, 0xe3?

Talked again with Claunia. It seems we should treat the 1st track as a separate track (18032 empty bytes + 106 frames), while tracks 2 and after are like a single track for the system. The main movie part is divided by tracks, yes, but it's not intended for playing/decoding the separate tracks. So the tracks 3 and beyond can start with incomplete frames and have any bytes there.

sarami wrote:

Does it mean incomplete frame belong track 02, not track 01?

http://redump.org/discs/system/hvnc/ -- all the dumps have the first track as 18032 empty bytes + 106 frames and they have the same CRC. If you shift the data, so they would start with a non-zero byte and have incomplete frames at the end - none of them match each other. That means the "incomplete" frame doesn't belong to the 1st track, because the 1st track is always standard (for the already dumped discs) and its data should be the same, while track 2 is, of course, always different, including its first frame.

2,024

user7 wrote:

Anything that can be done about it? Maybe modify DIC to handle data.dat like big.dat?

Not supported yet.

F1ReB4LL wrote:

while tracks 2 and after are like a single track for the system. The main movie part is divided by tracks, yes, but it's not intended for playing/decoding the separate tracks. So the tracks 3 and beyond can start with incomplete frames and have any bytes there.

Doesn't VideoNow Player support the track search like general CD player? If yes, it's inconvenient player...

F1ReB4LL wrote:

That means the "incomplete" frame doesn't belong to the 1st track, because the 1st track is always standard (for the already dumped discs) and its data should be the same, while track 2 is, of course, always different, including its first frame.

Even if VideoNow handles the disc like a single track, tracks themselves should be standalone according to the TOC and the correct combined offset, I think. Because VideoNow disc is multi track.

2,025

sarami wrote:

Doesn't VideoNow Player support the track search like general CD player?

It does, but think about audio cds: the data isn't always properly aligned on them. And there are many gapless discs, where the track numbers are only used to navigate inside the one big record.

sarami wrote:

Even if VideoNow handles the disc like a single track, tracks themselves should be standalone according to the TOC and the correct combined offset

Or you're just trying to align the data your own way smile

I think the explanation about the 1st track is always the same and the rest of the disc is always different, so the 1st track should be always aligned properly is correct.