476 Reply by pablogm123 (edited by pablogm123 2014-07-29 22:05:10)

  • From: Sevilla - España
  • Registered: 2011-05-16
  • Posts: 1,006

Latest unlocked firmware installed:

1_08Xrpc1.bin
CRC32: f5f14e42
MD5: e60760ed1f36ec457df4d833b1e6e06b
SHA-1: 6e920618c5aa242e1df7b2f9bdce13d177601577

Windows Server 2003 Ent. SP2, account with admin privileges and absolutely no 3rd filter drivers installed and no virtual drives, as said before, in my main OS this trash is banned. Sticked into the drive a conventional CDDA.

C:\>cachex.exe -i g:

CacheExplorer 0.8 - spath@cdfreaks.com

Drive on G is  PLEXTOR  DVDR   PX-755A   1.08

[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh A8h(FUA) 28h(FUA) D4h(FUA) D5h(FUA) D8h(FUA)

C:\>
On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot
  • Registered: 2006-12-24
  • Posts: 3,847

Probably you need XP/2003 to get D8h(FUA).

  • From: Sevilla - España
  • Registered: 2011-05-16
  • Posts: 1,006

Final test would be running DIC from an elevated command prompt line in these OS with UAC. I don't think that SPTI has changed so much in order to disable the D8h(FUA) command.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot
  • Registered: 2011-02-20
  • Posts: 1,745

pablogm123 wrote:
C:\>cachex.exe -i g:

CacheExplorer 0.8 - spath@cdfreaks.com

Drive on G is  PLEXTOR  DVDR   PX-755A   1.08

[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh A8h(FUA) 28h(FUA) D4h(FUA) D5h(FUA) D8h(FUA)

C:\>

Does your PX-755 supports D4h(FUA) D5h(FUA) too?

My PX-755
OS: Win7 pro sp1 64bit, firmware: official

CacheExplorer 0.8 - spath@cdfreaks.com

Drive on M is  PLEXTOR  DVDR   PX-755A   1.08

[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh 28h(FUA) D8h

It is repeated, CacheExplorer uses SPTI interface in "unreliable" manner.(= it has a defect.)
This tool doesn't get sense data, so an error doesn't show even if it failed to read.
In other words it is displayed when supported in spite of what doesn’t support it.

Probably you need XP/2003 to get D8h(FUA).

If so, I can code it but I can't test. Because I don't have already WinXP sad

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

480 Reply by r09

  • r09
  • Dumper
  • Offline
  • From: Spain
  • Registered: 2008-04-19
  • Posts: 316

You shoudn't need XP, this is my 708A on Windows 7 with a regular (non-elevated) command prompt:

D:\redump.org>cachex -i f:

CacheExplorer 0.8 - spath@cdfreaks.com

Drive on F is  PLEXTOR  DVDR   PX-708A   1.12

[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh A8h(FUA) 28h(FUA) D4h(FUA) D5h(FUA) D8h(FUA)
  • From: Sevilla - España
  • Registered: 2011-05-16
  • Posts: 1,006

sarami wrote:

If so, I can code it but I can't test. Because I don't have already WinXP sad

Code it, I have damaged discs likely recoverable via many rereads and the SysInternals' Desktops (so processes which will take a lot of time won't mess my main desktop and distract me) to test the FUA function.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot
  • Registered: 2011-02-20
  • Posts: 1,745

A bug was able to reappear when I uninstalled SPTD.(http://www.duplexsecure.com/en/downloads)

CacheExplorer 0.8 - spath@cdfreaks.com

Drive on H is  PLEXTOR  CD-R   PX-W5224A 1.04

[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh A8h(FUA) 28h(FUA) D4h(FUA) D5h(FUA) D8h(FUA)
CacheExplorer 0.8 - spath@cdfreaks.com

Drive on M is  PLEXTOR  DVDR   PX-755A   1.08

[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands: BEh A8h(FUA) 28h(FUA) D4h(FUA) D5h(FUA) D8h(FUA)

And I uploaded exe to test.
http://www.mediafire.com/download/dqzkl … stD8FUA.7z
To test, I changed below.
(SCSIOP_PLEX_READ_CD is 0xd8, CDB_FORCE_MEDIA_ACCESS is 0x08)

BOOL ReadCDForFlushingDriveCache(
    PDEVICE pDevice,
    INT nLBA
    )
{
#if 0
    CDB::_READ12 cdb = { 0 };
    cdb.OperationCode = SCSIOP_READ12;
    cdb.ForceUnitAccess = CDB_FORCE_MEDIA_ACCESS;
    cdb.LogicalUnitNumber = pDevice->address.Lun;
    cdb.LogicalBlock[0] = HIBYTE(HIWORD(nLBA + 1));
    cdb.LogicalBlock[1] = LOBYTE(HIWORD(nLBA + 1));
    cdb.LogicalBlock[2] = HIBYTE(LOWORD(nLBA + 1));
    cdb.LogicalBlock[3] = LOBYTE(LOWORD(nLBA + 1));
#else
    CDB::_PLXTR_READ_CDDA cdb = { 0 };
    cdb.OperationCode = SCSIOP_PLEX_READ_CD;
    cdb.Reserved0 = CDB_FORCE_MEDIA_ACCESS;
    cdb.LogicalUnitNumber = pDevice->address.Lun;
    cdb.LogicalBlockByte0 = HIBYTE(HIWORD(nLBA + 1));
    cdb.LogicalBlockByte1 = LOBYTE(HIWORD(nLBA + 1));
    cdb.LogicalBlockByte2 = HIBYTE(LOWORD(nLBA + 1));
    cdb.LogicalBlockByte3 = LOBYTE(LOWORD(nLBA + 1));
    cdb.TransferBlockByte3 = 1;
#endif
    BYTE byScsiStatus = 0;
    if (!ScsiPassThroughDirect(pDevice, &cdb, CDB12GENERIC_LENGTH, NULL,
        0, &byScsiStatus, _T(__FUNCTION__), __LINE__)
        || byScsiStatus >= SCSISTAT_CHECK_CONDITION) {
        return FALSE;
    }
    return TRUE;
}

Result:
I understood that I did not work as expected.

ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    197/222682[F:ReadCDForFlushingDriveCache][L:516] OperationC
ode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    198/222682[F:ReadCDForFlushingDriveCache][L:516] OperationC
ode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    199/222682[F:ReadCDForFlushingDriveCache][L:516] OperationC
ode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    200/222682[F:ReadCDForFlushingDriveCache][L:516] OperationC
ode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    201/222682[F:ReadCDForFlushingDriveCache][L:516] OperationC
ode: 0xd8

If you think that FUA exists in 0xd8 command, please teach me it except for CacheExplorer.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

  • Registered: 2006-12-24
  • Posts: 3,847

Could you finally fix the rereading for C2 errors? It doesn't work in the Test (20140720) version, it doesn't work in the Release(20140621), only works in the old 2013 releases.

Change reading speed: 4x
Reread times    1, ErrSectorNum   48/  48
Reread times    2, ErrSectorNum   48/  48
C2 error was fixed at all

Change reading speed: 4x
Reread times    1, ErrSectorNum   51/  51
Reread times    2, ErrSectorNum   51/  51
Reread times    3, ErrSectorNum    2/   2
Reread times    4, ErrSectorNum    2/   2
C2 error was fixed at all

Change reading speed: 4x
Reread times    1, ErrSectorNum   51/  51
Reread times    2, ErrSectorNum   51/  51
Reread times    3, ErrSectorNum    2/   2
Reread times    4, ErrSectorNum    1/   1
Reread times    5, ErrSectorNum    1/   1
C2 error was fixed at all

So it rereads 3-4 times and says all the errors are fixed, but nothing is fixed, it's a bug. Releases from 2013 reread properly.

  • From: Sevilla - España
  • Registered: 2011-05-16
  • Posts: 1,006

EAC's developer should know something, because EAC has D8 support for these vintage SCSI CD-ROM readers, for C2 pointers and for FUA (-usefua parameter, and you have to configure drive as non-caching one).

And:

SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    379/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    380/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    381/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    382/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    383/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    384/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    385/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    386/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    387/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    388/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    389/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    390/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    391/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
ScsiStatus: 02, CHECK_CONDITION
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)    392/ 69300[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8

So that only normal 0xA8 command is valid for FUA, and you cannot use this one for extracting data sectors in scrambled form.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot
  • Registered: 2008-03-10
  • Posts: 355

Just program a new tool that can test if a drive supports 0xD8 FUA, if cachex is unreliable tongue

  • Registered: 2006-12-24
  • Posts: 3,847

sarami wrote:

And I uploaded exe to test.
http://www.mediafire.com/download/dqzkl … stD8FUA.7z

Works here:

DiscImageCreatorToTestD8FUA.exe cd H: dump 40 /c2 1024 1024 4
OS
        Windows 7 Ultimate Service Pack 1 64bit
AppVersion
        x86, AnsiBuild, Jul 31 2014 03:39:08
CurrentDir
        D:\1
InputPath
         path: dump
        drive:
          dir:
        fname: dump
          ext:
Start: 2014-08-01(Fri) 04:43:14
Checking reading lead-out
Creating bin from 4419 to 4421 (LBA)   4421
Reading lead-out: OK
Allocating memory for C2 error: 1024/1024
Operation Code: 0xd8, Sub Code: Raw
Creating img(LBA)   4420/  4418
C2 error didn't exist
Copying .scm to .img
Descrambling data sector of img(LBA)   3250/  3250
Checking ecc/edc LBA   4418/  4418
User data vs. ecc/edc match all
Creating bin, cue, ccd(Track)  2/ 2
Free memory for C2 error: 1024/1024
Calculating hash: dump (Track 1).bin
Calculating hash: dump (Track 2).bin
Calculating hash: dump.img

End: 2014-08-01(Fri) 04:43:42

http://redump.org/disc/8037/ - this game.

But I've updated Daemon Tools yesterday, cachex shows now:

cachex.exe -i -p -c h:

CacheExplorer 0.8 - spath@cdfreaks.com

Drive on H is  PLEXTOR  DVDR   PX-760A   1.07
[+] Buffer size: 2048 kB, read cache is enabled
[+] Supported read commands:
[+] Plextor flush command: rejected
[+] Testing cache line size:

So maybe it works because of new DT with SPTD 1.86? smile

  • Registered: 2011-02-20
  • Posts: 1,745

F1ReB4LL wrote:

Could you finally fix the rereading for C2 errors? It doesn't work in the Test (20140720) version, it doesn't work in the Release(20140621), only works in the old 2013 releases.

I'll check it.

F1ReB4LL wrote:

DiscImageCreatorToTestD8FUA.exe cd H: dump 40 /c2 1024 1024 4

If you use FUA, please use /f option.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

  • From: Sevilla - España
  • Registered: 2011-05-16
  • Posts: 1,006

Is the offset correction applied for the C2 pointers as well? Perhaps this has something to do with the recent bug I discovered, C2 file was bigger than expected.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot
  • Registered: 2006-12-24
  • Posts: 3,847

sarami wrote:
F1ReB4LL wrote:

DiscImageCreatorToTestD8FUA.exe cd H: dump 40 /c2 1024 1024 4

If you use FUA, please use /f option.

Yes, with /f it fails smile

...
SenseData Key-Asc-Ascq: 05-24-00, ILLEGAL_REQUEST - INVALID FIELD IN CDB
Creating img(LBA)     25/250866[F:ReadCDForFlushingDriveCache][L:516] OperationCode: 0xd8
...

490 Reply by pablogm123 (edited by pablogm123 2014-08-02 12:18:55)

  • From: Sevilla - España
  • Registered: 2011-05-16
  • Posts: 1,006

Observe this carefully in the sample you have posted. If you compare R-W data extracted via these two modes, they look different.

====== Check SubP to W, OperationCode: 0xbe, Subcode: 1(=Raw) ======
Sub Channel LBA 0
      +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 02 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 00 00 00 03
    T 00 00 00 00 00 00 00 00 00 00 00 02
    U 00 00 00 00 00 00 00 00 00 00 00 00
    V 00 00 00 00 00 00 00 00 00 00 00 00
    W 00 00 00 00 00 00 00 00 00 00 00 02

====== Check SubP to W, OperationCode: 0xd8, Subcode: 0x08(=Raw) ======
Sub Channel LBA 0
      +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 02 00 28 32
    R 00 00 00 00 00 00 00 00 00 00 00 01
    S 00 00 00 00 00 00 00 00 00 00 00 03
    T 00 00 00 00 00 00 00 00 00 00 00 02
    U 00 00 00 00 00 00 00 00 00 00 00 00
    V 00 00 00 00 00 00 00 00 00 00 00 03
    W 00 00 00 00 00 00 00 00 00 00 00 00


Two samples I have prepared for you:

http://www.mediafire.com/?lhad50oqouoznsv

C2 + Raw sub 96 extracted via certain method via D8 command, and the same thing via BE command, audio trap disc (so subcodes will be always properly aligned in the BE mode, especially true for certain buggy drives which lose the sync in the data-audio [or viceversa] transitions) method. Both look at first sight more or less identical. They contain lots of random errors, as expected for a subcode extracted without any class of rereadings/cleanings and whatnot, though.

I am wondering if this pattern could be predictable. And the reason of its existence: intentional, an accidental mastering artifact...?

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot
  • Registered: 2011-02-20
  • Posts: 1,745

pablogm123 wrote:

====== Check SubP to W, OperationCode: 0xbe, Subcode: 1(=Raw) ======
Sub Channel LBA 0
      +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 02 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 00 00 00 03
    T 00 00 00 00 00 00 00 00 00 00 00 02
    U 00 00 00 00 00 00 00 00 00 00 00 00
    V 00 00 00 00 00 00 00 00 00 00 00 00
    W 00 00 00 00 00 00 00 00 00 00 00 02

====== Check SubP to W, OperationCode: 0xd8, Subcode: 0x08(=Raw) ======
Sub Channel LBA 0
      +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 02 00 28 32
    R 00 00 00 00 00 00 00 00 00 00 00 01
    S 00 00 00 00 00 00 00 00 00 00 00 03
    T 00 00 00 00 00 00 00 00 00 00 00 02
    U 00 00 00 00 00 00 00 00 00 00 00 00
    V 00 00 00 00 00 00 00 00 00 00 00 03
    W 00 00 00 00 00 00 00 00 00 00 00 00

I uploaded exe including this function.


I am wondering if this pattern could be predictable. And the reason of its existance: intentional, an accidental mastering artifact...?

I don't know this pattern in detail too...

And
To: axisleon
subject: DC ripping is very slow
Improved it. Please test.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

  • From: Sevilla - España
  • Registered: 2011-05-16
  • Posts: 1,006

Tested:

http://www.mediafire.com/?6w3noqvyw4glvit

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot
  • Registered: 2006-12-24
  • Posts: 3,847

/m      If MCN sector exists in the last sector of the track, use this
                For WonderMega Collection [Mega-CD]

On Mega CD and Saturn titles MCN is always in the last sector of the track. Only PCE titles have MCN in the first sector of the track. You should treat MCN sectors as the last sector of the track by default. And "/m" parameter should be for PCE discs, where "MCN sector exists in the first sector of the track".

  • Registered: 2011-02-20
  • Posts: 1,745

F1ReB4LL wrote:

/m      If MCN sector exists in the last sector of the track, use this
                For WonderMega Collection [Mega-CD]

On Mega CD and Saturn titles MCN is always in the last sector of the track. Only PCE titles have MCN in the first sector of the track. You should treat MCN sectors as the last sector of the track by default. And "/m" parameter should be for PCE discs, where "MCN sector exists in the first sector of the track".

Indeed? Fixed it.

DiscImageCreator, UmdImageCreator, Conv2multiBin, bin2wav, PS3Auth (needs login), recompressTo7z_20150109.bat

sarami's Website

  • From: Sevilla - España
  • Registered: 2011-05-16
  • Posts: 1,006

Sure:

http://redump.org/disc/30958/
http://redump.org/disc/32498/
http://redump.org/disc/32560/

These discs sometimes contain a MCN frame in certain audio tracks transitions, where there are no indexes 00 and whatnot in these audio-audio transitions. Those frames belong logically to the next track, as dicted by the TOC.

Certain buggy app (well, not optimized to dump game discs with audio tracks) used in the past (EAC) treated these things as artificial indexes 00, especially when combined with TOC versus subcode desyncs.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot
  • Registered: 2006-12-24
  • Posts: 3,847

pablogm123 wrote:

These discs sometimes contain a MCN frame in certain audio tracks transitions, where there are no indexes 00 and whatnot in these audio-audio transitions. Those frames belong logically to the next track, as dicted by the TOC.

Certain buggy app (well, not optimized to dump game discs with audio tracks) used in the past (EAC) treated these things as artificial indexes 00, especially when combined with TOC versus subcode desyncs.

No, I've asked to assign these sectors to the previous track by default, since many Saturn and Mega CD ones are mastered this way. Only PCE CD discs need EAN sectors assigned to the next track. Default - EAN goes to the previous sector, /m - EAN goes to the next sector smile

  • From: Sevilla - España
  • Registered: 2011-05-16
  • Posts: 1,006

Only example I have physically (or at least I am aware of that) with that kind of "colission" is track 35 of /disc/29188/. A MCN frame appears in the track 34 - index 01 / track 35 - index 00 transition.

http://i.imgur.com/Kp1FVBw.png

That MCN frame belongs to previous track, pregap is 00:02:02 (Sony style) and, at least this one, was ripped finely by DIC without doing anything special. I didn't specify any /m parameter even if back then was already encoded.

Proof:
https://www.mediafire.com/?3z1r6o4yxe9d7om

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot

498 Reply by MrX_Cuci (edited by MrX_Cuci 2014-08-17 14:03:36)

  • Registered: 2008-03-02
  • Posts: 810

Motormash probleem seems to be fixed in latest build. Image is being created now.

How to fix c2 errors by the way. Is it done automatically and how to verify it is indeed fixed?

499 Reply by pablogm123 (edited by pablogm123 2014-08-17 15:27:04)

  • From: Sevilla - España
  • Registered: 2011-05-16
  • Posts: 1,006

Simply, via rereading lots of times the bad sectors until being lucky and get a reread without C2 errors for any bad sector. Not always possible, though.

If the disc to dump is really in awful condition (label side heavily scratched, corroded by long exposition to water, disc edge bad sealed and metallic layer is corroded by oxygen...), no matter how much you reread the problematic sectors, data returned will be always bad and therefore unrecoverable. Miracles don't exist.

On semi-vacation. MSF/AMSF to LBA/offset and viceversa calculator: link
To write properly occidental characters contained in japanese titles: screenshot
Spaces must be the fullwidth variant: link / screenshot
  • Registered: 2006-12-24
  • Posts: 3,847

MrX_Cuci wrote:

Is it done automatically and how to verify it is indeed fixed?

C2 rereading is broken in DIC.