You are not logged in. Please login or register.
Redump Forum → General discussion → DiscImageCreator
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
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 
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?
I created PVDTools(https://github.com/saramibreak/PVDTools) to decode VideoNow disc.
Please decode your VideoNow disc, using this tool.
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.
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.
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)
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 
Why was the track type set to audio in the cue?
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?
The two 708 dumps don't match hashes
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..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
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.
Thanks for the sub channel crc fix.
Any progress on backwards dumping?
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
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.
Thanks for the sub channel crc fix.
But this problem (http://forum.redump.org/topic/18552/meg … e-kingpin/) occurs again.
Any progress on backwards dumping?
In the near future.
it looks like the cue file is broken because of CDTEXT
Perhaps, it needs unicode. I'll support it.
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.
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.
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.
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.
She says the frames are solid and shouldn't be split between tracks.
Does it mean incomplete frame belong track 02, not track 01?
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.
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?
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.
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.
Could you also make it so it doesn't abort on C2 errors or a switch for it, sectors may be correctable with ECC.
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
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;1Anything that can be done about it? Maybe modify DIC to handle data.dat like big.dat?
Thanks.
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.
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.
Anything that can be done about it? Maybe modify DIC to handle data.dat like big.dat?
Not supported yet.
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...
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.
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.
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
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.
Redump Forum → General discussion → DiscImageCreator
Powered by PunBB 1.4.4, supported by Informer Technologies, Inc.
Currently installed 6 official extensions. Copyright © 2003–2009 PunBB.