DiscImageCreator

[sarami]

I have a problem with another multi-platform disc (mainly Amiga) : Dream 41

Test build
https://www.mediafire.com/file/eq80y20l … st.7z/file

[Novicami]

I have a problem with another multi-platform disc (mainly Amiga) : Dream 41

Test build
https://www.mediafire.com/file/eq80y20l … st.7z/file

Everything seems to be going well now!
Logs here

[sarami]

https://github.com/saramibreak/DiscImag … g/20220606
*2022-06-06
- added: check Latin-1 character when reading DirectoryRecord
- added: support CD-TEXT with Unicode
- changed: PFI.bin to (fname)_PFI.bin and DMI, SS, PIC are also the same
- fixed: when subQ is fixed, if the adr of next subQ is not 1, prev subQ is used
- fixed: allow "Data Length 0" (for some linux and amiga disc)

[Neon Beast]

It has some weird CD-text, probably causing the problem.

CD-TEXT supports "ISO/IEC 8859-1", "ISO/IEC 646", "MS-JIS (CP932, SJIS)" https://www.gnu.org/software/libcdio/cd … 80x8f_0029
But this disc uses Unicode. Therefore, unicode needs the conversion to these character codes.

Added. https://www.mediafire.com/file/eq80y20l … st.7z/file

Dumped with the latest release, CD-TEXT not showing correctly, is this normal?

https://mega.nz/file/CrwAUaCa#5nNUtqJzY … OYvM3zGwSI

[sarami]

CD-TEXT not showing correctly, is this normal?

I tested it using same CD-TEXT data, and it's no problem. I'm not sure why the string is not showed correctly.

Code: Select all

========== CDTEXT ==========
    Entry 0 crc[0657] is good
    Entry 1 crc[315e] is good
    Entry 2 crc[7786] is good
    Entry 3 crc[e163] is good
    Entry 4 crc[9205] is good
    Entry 5 crc[bc6b] is good
    Entry 6 crc[bf6d] is good
    Entry 7 crc[2729] is good
    Entry 8 crc[3b44] is good
    Entry 9 crc[23ae] is good
    Entry 10 crc[4a86] is good
    Entry 11 crc[d75d] is good
    Entry 12 crc[828e] is good
    Entry 13 crc[5537] is good
    Entry 14 crc[9619] is good
    Entry 15 crc[6544] is good
    Entry 16 crc[db0b] is good
    Entry 17 crc[94d5] is good
    Entry 18 crc[a4af] is good
    Entry 19 crc[d9d4] is good
    Entry 20 crc[e416] is good
    Entry 21 crc[6e59] is good
    Entry 22 crc[c7ec] is good
    Entry 23 crc[ffb4] is good
    Entry 24 crc[c835] is good
    Entry 25 crc[bf60] is good
    Entry 26 crc[bace] is good
    Entry 27 crc[a5a8] is good
    Entry 28 crc[3176] is good
    Entry 29 crc[bca4] is good
    Album Name: 新しいタイトル (7)
     Song Name[1]: トラック 01
     Song Name[2]: トラック 02
     Song Name[3]: トラック 03
     Song Name[4]: トラック 04
     Song Name[5]: トラック 05
     Song Name[6]: トラック 06
     Song Name[7]: トラック 07
     Song Name[8]: トラック 08
     Song Name[9]: トラック 09
     Song Name[10]: トラック 10
    Album Performer: 新しいアーティスト (7)
    First track number: 1
     Last track number: 10
         Lead-out(msf): 44:04:61
          Track 1(msf): 00:02:00
          Track 2(msf): 04:15:27
          Track 3(msf): 08:23:64
          Track 4(msf): 12:50:19
          Track 5(msf): 17:07:59
          Track 6(msf): 21:30:44
          Track 7(msf): 25:54:34
          Track 8(msf): 30:08:20
          Track 9(msf): 34:48:37
          Track 10(msf): 39:36:00
             Character code for this BLOCK: 0x00 (ISO/IEC 8859-1 [Latin-1])
                        First track Number: 1
                         Last track Number: 20
                             Mode2 PACKETs: No
              Program area copy protection: No
                Copyright asserted for $85: Yes
            Copyright asserted for $81-$84: Yes
                Copyright asserted for $80: Yes
    Number of PACKS with $80 (ALBUM_NAME) : 17
    Number of PACKS with $81 (PERFORMER)  : 6
    Number of PACKS with $82 (SONGWRITER) : 0
    Number of PACKS with $83 (COMPOSER)   : 0
    Number of PACKS with $84 (ARRANGER)   : 0
    Number of PACKS with $85 (MESSAGES)   : 0
    Number of PACKS with $86 (DISC_ID)    : 0
    Number of PACKS with $87 (GENRE)      : 0
    Number of PACKS with $88 (TOC_INFO)   : 4
    Number of PACKS with $89 (TOC_INFO2)  : 0
    Number of PACKS with $8a              : 0
    Number of PACKS with $8b              : 0
    Number of PACKS with $8c              : 0
    Number of PACKS with $8d (CLOSED_INFO): 0
    Number of PACKS with $8e (UPC_EAN)    : 0
    Number of PACKS with $8f (SIZE_INFO)  : 3
           Last Sequence number of BLOCK 0: 29
           Last Sequence number of BLOCK 1: 0
           Last Sequence number of BLOCK 2: 0
           Last Sequence number of BLOCK 3: 0
           Last Sequence number of BLOCK 4: 0
           Last Sequence number of BLOCK 5: 0
           Last Sequence number of BLOCK 6: 0
           Last Sequence number of BLOCK 7: 0
                     Language code BLOCK 0: 0x69 (Japanese)
                     Language code BLOCK 1: 0x00 (not applicable)
                     Language code BLOCK 2: 0x00 (not applicable)
                     Language code BLOCK 3: 0x00 (not applicable)
                     Language code BLOCK 4: 0x00 (not applicable)
                     Language code BLOCK 5: 0x00 (not applicable)
                     Language code BLOCK 6: 0x00 (not applicable)
                     Language code BLOCK 7: 0x00 (not applicable)

[Zuk60]

I am planning to use DIC to archive my CDDA audio CDs (via a Plextor 760A).

Is there any way to populate the resultant .cue file with metadata from discogs, musicbrainz etc?

[ehw]

Hey sarami I have a question about your .c2 format.

According to your readme, 1 bit inside the .c2 file represents 1 byte in the disc image. But there isn't any additional information besides that. I can assume that 0 means no c2 error and 1 means c2 error, but I'm having a difficult time trying to determine how the bits correlate to the exact locations of the bytes in the disc image.

For instance, let's say I had two incomplete dumps that have c2 errors in both, like this:

https://i.imgur.com/lXPQHId.png

According to the .c2 for one dump, I have one C2 error ($01) somewhere in the 8 bytes that should correlate to 0xC3 in this .c2 file. In the other dump, there are no errors for this equivalent area as the byte is set to $00. If you take 0xC3 and multiply it by 8, you should get the address for the group of 8 bytes this error represents, which in this case is 0x618 in the image file.

https://i.imgur.com/RtJMP96.png

I assume that the bits correlate to the bytes in LSB order. So since $01 is 00000001 in binary, there should be an error that affects just 1 byte around 0x618-0x61F, in this case the c2 error should be on 0x61F. But when comparing both image dumps, there are TWO bytes that differ rather than one.

I don't think I understand how the .c2 file actually correlates to the image file. Can you explain how?

[superg]

Hey sarami I have a question about your .c2 format.

According to your readme, 1 bit inside the .c2 file represents 1 byte in the disc image. But there isn't any additional information besides that. I can assume that 0 means no c2 error and 1 means c2 error, but I'm having a difficult time trying to determine how the bits correlate to the exact locations of the bytes in the disc image.

Please see my reply here: /viewtopic.php?p=26420#p26420

I assume that the bits correlate to the bytes in LSB order. So since $01 is 00000001 in binary, there should be an error that affects just 1 byte around 0x618-0x61F, in this case the c2 error should be on 0x61F. But when comparing both image dumps, there are TWO bytes that differ rather than one.

C2 is usually big endian (MSB) with some drive exceptions.
Also, you see two damaged bytes per 1 C2 bit set only for sectors that are scrambled, I guess this is how scrambling implemented on hardware level.

Talk to me on Discord (superg#9200)

[ehw]

Hey sarami I have a question about your .c2 format.

According to your readme, 1 bit inside the .c2 file represents 1 byte in the disc image. But there isn't any additional information besides that. I can assume that 0 means no c2 error and 1 means c2 error, but I'm having a difficult time trying to determine how the bits correlate to the exact locations of the bytes in the disc image.

Please see my reply here: /viewtopic.php?p=26420#p26420

I assume that the bits correlate to the bytes in LSB order. So since $01 is 00000001 in binary, there should be an error that affects just 1 byte around 0x618-0x61F, in this case the c2 error should be on 0x61F. But when comparing both image dumps, there are TWO bytes that differ rather than one.

C2 is usually big endian (MSB) with some drive exceptions.
Also, you see two damaged bytes per 1 C2 bit set only for sectors that are scrambled, I guess this is how scrambling implemented on hardware level.

Talk to me on Discord (superg#9200)

Thanks for the response.

That's a little concerning. I assumed each bit .c2 would map directly to the bytes in the .scm since those two files are always generated first by DIC but I wasn't aware they could be offset by drive...

If you look at the Beyond Compare image there are actually some groups of 8 bytes where only one of the bytes is different. For instance, the 5th byte (at 0x91C) in the group of 8 bytes at 0x918 in the .scm file apparently correlates to 0x123 in the .c2 file. In dump 1, the value at 0x123 in the .c2 file is $0F (00001111) and in dump 2 this value is $0D (00001101). I did descramble the two .scm dumps I was comparing using ISOBuster and the placement of the byte differences are the same as in the scrambled, just the values are obviously different. I descrambled the file by saving the CD image as a .bin (Extract CD image -> Raw .bin).

[MrTikki]

@sarami: Just thinking outside the box here...and if this feature is already in place and I missed it feel FREE to correct me...but rather than exporting all of the data dumps into a flat, text file...it seems like it would be more beneficial if the data were also exported in a supplemental CSV format. This way we could eventually use the CSV format to streamline disc uploads by auto-populating the data fields by uploading the CSV directly.

Again, just an idea. And if it already exists...awesome!

Cheers!
-MrTikki-