901

(1 replies, posted in Guests & account requests)

In a what way?

902

(4 replies, posted in Guests & account requests)

Hiccup wrote:

Will you share a link to your essay when its done? smile

I've written a text about offset correction techniques for the English exam maybe 10 years ago smile

903

(15 replies, posted in General discussion)

fuzzball wrote:

In the first place, why "ō" was "ou"?

Toukyou – written using kana spelling: ō as ou or oo (depending on the kana) and ū as uu. That is sometimes called wāpuro style, as it is how text is entered into a Japanese word processor by using a keyboard with Roman characters. The method most accurately represents the way that vowels are written in kana by differentiating between おう (as in とうきょう(東京), written Toukyou in this system) and おお (as in とおい(遠い), written tooi in this system). However, using this method makes the pronunciation of ou become ambiguous, either a long o or two different vowels: o and u.

https://en.wikipedia.org/wiki/Hepburn_r … Variations

Unlike Kunrei and Hepburn, wāpuro style is based on a one-to-one transcription of the kana.[1] Wāpuro thus does not represent some distinctions observed in spoken Japanese, but not in writing, such as the difference between /oː/ (long vowel) and /oɯ/ (o+u). For example, in standard Japanese the kana おう can be pronounced in two different ways: as /oː/ meaning "king" (王),[2] and as /oɯ/ meaning "to chase" (追う).[3] Kunrei and Hepburn spell the two differently as ō and ou, because the former is a long vowel while the latter has a o that happens to be followed by a u; however, wāpuro style simply transcribes the kana and renders them both as ou.

https://en.wikipedia.org/wiki/W%C4%81pu … c_accuracy

904

(11 replies, posted in General discussion)

iR0b0t wrote:

0x00 sounds okay for DVD sector replacement, at least i feel so.

That makes bad sectors undistinguishable from empty sectors.

iR0b0t wrote:

If i remember correctly SS areas of Xbox discs aren't stable, each ss range has different amount of readable sectors in the beginning and in the end, and if i recall it right the amount of readable sectors differs also between drives.

The contents is stable, the amount of readable sectors may differ a little between the drives, but that's due to the nature of these sectors, anyway, it seems nobody has even tried to preserve them.

905

(3,521 replies, posted in General discussion)

He got a 2.6GB image instead of the standard 7825162240-bytes one.

906

(11 replies, posted in General discussion)

iR0b0t wrote:
sarami wrote:

Of course, If you say all sectors in sector range should be preserved by zero, I don't say anymore.

Back then when we first started preserving xbox stuff we talked about this topic and agreed to skip ALL possible ss ranges, because we find that most likelly xbox skippes those ranges anyways. This is similar to SafeDisc and other PC protections where we skip bad sectors even if there may be some data readable.

Aren't we skipping the SafeDisc and similar sectors due to their instability (unconstant reads between different drives)? While SS sectors are quite stable and there are only about 305-320 unreadable sectors starting after 1270-1285 readable sectors in each 4096-byte SS area (with all 4096 bytes readable in certain cases)? And aren't we replacing the unreadable sectors with 0x55 not 0x00?

907

(15 replies, posted in General discussion)

Talking about Ou-chan: do you think "Ou/Oo" is a native Japanese word? Or should it be treated as a borrowed word "Oh"?

908

(3,521 replies, posted in General discussion)

sarami wrote:

I can't understand how to use the FixLevel/[FixLevel] bits.

FixLevel = 1

if (Q-CRC of QCurrentSector is bad) {
    create QGenSector1 from QNextSector - 1
   
    compare 96bits of QCurrentSector and QGenSector1
   
    if (the difference is 1-bit) {
        QCurrentSector = QGenSector1
    }
    else {
       create QGenSector2 from QPrevSector + 1

       compare 96bits of QCurrentSector and QGenSector2

       if (the difference is 1-bit) {
        QCurrentSector = QGenSector2
       }
       else {   
          try to change each bit to opposite (Max 96 times)    // for the case when QCurrentSector and QGenSector are different
          if not success {     
             reread sector (*1)
          }
       }
    }

FixLevel = 2

if (Q-CRC of QCurrentSector is bad) {
    create QGenSector1 from QNextSector - 1
   
    compare 96bits of QCurrentSector and QGenSector1
   
    if (the difference is 2-bit or less) {
        QCurrentSector = QGenSector1
    }
    else {
       create QGenSector2 from QPrevSector + 1

       compare 96bits of QCurrentSector and QGenSector2

       if (the difference is 2-bit or less) {
        QCurrentSector = QGenSector2
       }
       else {   
          try to change each bit to opposite (Max 96*96? times)    // for the case when QCurrentSector and QGenSector are different
          if not success {     
             reread sector (*1)
          }
       }
    }

FixLevel = 3

if (Q-CRC of QCurrentSector is bad) {
    create QGenSector1 from QNextSector - 1
   
    compare 96bits of QCurrentSector and QGenSector1
   
    if (the difference is 3-bit or less) {
        QCurrentSector = QGenSector1
    }
    else {
       create QGenSector2 from QPrevSector + 1

       compare 96bits of QCurrentSector and QGenSector2

       if (the difference is 3-bit or less) {
        QCurrentSector = QGenSector2
       }
       else {   
          try to change each bit to opposite (Max 96*96*96? times)    // for the case when QCurrentSector and QGenSector are different
          if not success {     
             reread sector (*1)
          }
       }
    }

sarami wrote:

Who fixes the 1-bit error of QCurrentSector? Isn't it fixed by changing each bit to opposite?

Comparing QCurrentSector and QGenSector1 and QCurrentSector and QGenSector2 are 2 operations, changing the bits is 96^FixLevel operations, much longer. So it's faster to compare with the generated sector first. Maybe also worth to add a flag not to use the bit changing, if the difference between QCurrentSector and QGenSector1 or QCurrentSector and QGenSector2 is FixLevel+1 ... FixLevel+9 bits then not to use the bits changing for this sector.

For example:

FixLevel = 1

compare 96bits of QCurrentSector and QGenSector1

QCurrentSector = 0101010101
QGenSector1 =  0111010111

Difference: 2 bits. 2 bits is between "FixLevel+1 ... FixLevel+9", so you don't change the bits, you reread the sector.
   
Or:

FixLevel = 1

compare 96bits of QCurrentSector and QGenSector1

QCurrentSector = 010101010101
QGenSector1 = 101010101010

Difference: 12 bits. 12 bits is more than FixLevel+9, so we assume the sector is probably of a different type than generated sector and we're trying to change the bits before rereading.

909

(15 replies, posted in General discussion)

https://ja.wikipedia.org/wiki/動物 => 動物 = どうぶつ = "do + u + bu + tsu".
https://ja.wikipedia.org/wiki/番長 => 番長 = ばんちょう = "ba + n + cho + u"

I don't know. Both "dou" and "doo" for "ドー" are correct as a representation of "dō" - https://en.wikipedia.org/wiki/Hepburn_r … Variations
But as far as I understand, No-Intro uses "Ou" for these with the exception for things like "ōkami", which transcription isn't "オーカミ", but "オオカミ".

fuzzball wrote:

It was my mistake.
Please fix http://redump.org/discs/quicksearch/nampasen/

Btw, are you sure the Mac version should have "The"? http://buyee.jp/item/yahoo/auction/b271726888 -- this version? no "the"...

910

(15 replies, posted in General discussion)

fuzzball wrote:

doubling vowels.

What's about other non-English titles with "ー"?
http://redump.org/discs/quicksearch/ボボボーボ/ -- these are "Boboboobo Boobobo", then?
http://redump.org/disc/42653/ -- and this one? Choukou Senki Kikaioo?
http://redump.org/disc/24802/ -- Doubutsu Banchoo?

911

(15 replies, posted in General discussion)

fuzzball wrote:

http://redump.org/discs/quicksearch/ou-chan-oekaki/
wrong : Ou-chan no Oekaki Logic
correct: Oo-chan no Oekaki Logic

Why? http://forum.redump.org/post/49227/#p49227

fuzzball wrote:

http://redump.org/disc/53974/
wrong:  Shaman King: Funbari Spirits
correct: Shaman King: Fumbari Spirits


http://redump.org/discs/quicksearch/ganbare/
wrong:  ganbare
correct: gambare


http://redump.org/discs/quicksearch/nban/
wrong:  kanzenban, taikenban, etc.
correct: kanzemban, taikemban, etc. (or kanzen-ban, taiken-ban ?)

No. https://en.wikipedia.org/wiki/Hepburn_romanization

In modified Hepburn:
The rendering m before labial consonants is not used and is replaced with n. It is written n' (with an apostrophe) before vowels and y.
案内(あんない): annai – guide
群馬(ぐんま): Gunma – Gunma
簡易(かんい): kan'i – simple
信用(しんよう): shin'yō – trust

912

(3,521 replies, posted in General discussion)

sarami wrote:

Like this?

if (Q-CRC of QCurrentSector is bad) {
    create QGenSector from QNextSector - 1
    
    compare 96bits of QCurrentSector and QGenSector
    
    if (these sectors have 1-bit error) {
        try to change each bit to opposite (Max 96 times?)
    }
    else if (these sectors have 2 or more bit errors) {
        reread sector (*1)
    }
}

More like:

if (Q-CRC of QCurrentSector is bad) {
    create QGenSector from QNextSector - 1
    
    compare 96bits of QCurrentSector and QGenSector
    
    if (these sectors have >[FixLevel]-bit error) {
        QCurrentSector = QGenSector
    }
    else {
        try to change each bit to opposite (Max 96 times)    // for the case when QCurrentSector and QGenSector are different
        if not success {     
           reread sector (*1)
    }
}

Or:

if (Q-CRC of QCurrentSector is bad) {
    create QGenSector1 from QNextSector - 1
    
    compare 96bits of QCurrentSector and QGenSector1
    
    if (these sectors have >[FixLevel]-bit error) {
        QCurrentSector = QGenSector1
    }
    else {
       create QGenSector2 from QPrevSector + 1

       compare 96bits of QCurrentSector and QGenSector2

       if (these sectors have >[FixLevel]-bit error) {
        QCurrentSector = QGenSector2
       }
       else {   
          try to change each bit to opposite (Max 96 times)    // for the case when QCurrentSector and QGenSector are different
          if not success {     
             reread sector (*1)
          }
       }
    }

Comparing with both QNextSector-1 and QPrevSector+1 would help with pregap areas.

Also, you can try to change not only 1 bit to opposite, but [FixLevel] bits, should be something like 96^2 variants for FixLevel=2, etc., but I don't know about the speed of such calculations.

Question
(*1). How many times subdump reread the sector? If it can't get the good Q-CRC, is the sector written to file with being bad?

Defined by -rereadnum commandline option.

913

(3,521 replies, posted in General discussion)

sarami wrote:

1. What FixLevel? Default of subdump is 96?

FixLevel defines an acceptable level of errors. More errors than FixLevel - reread, do not fix. Each channel is 12 bytes/96 bits. 'Default' for subdump is 1 (it's not changeable). 1-bit errors are fixed automatically; if any of the channels from the read sub sector is different to the generated one in 2 or more bits - subdump rereads that sector (then counts the different bits and accepts the rereading results if the number of different bits lowered).

sarami wrote:

2. If QNextSector is 1st pregap sector, Is QGenSector really correct?
3. If QCurrentSector is track 1 and QNextSector is track 2, is QGenSector really correct?
4. If QCurrentSector is index 1 and QNextSector is index 2, is QGenSector really correct?
5. If QCurrentSector is ctl 0 and QNextSector is ctl 4, is QGenSector really correct?

No, that's why we check for Q-CRC. Even if the QCurrentSector is different to QNextSector, but QCurrentSector's Q-CRC is good, you continue to read.
Of course, you can try to generate all kinds of sectors and compare against them.

6. If adr of QCurrentSector is 1 but actually QCurrentSector is EAN sector, is the adr really fixed?
7. If adr of QCurrentSector is 3 but actually QCurrentSector is EAN sector, is the adr really fixed?
8. If adr of QCurrentSector is 2 but actually QCurrentSector is ISRC sector, is the adr really fixed?
9. If adr of QCurrentSector is 2 but actually QCurrentSector is normal sector, is the adr really fixed?

Same, it checks for Q-CRC and rereads, if it doesn't match.

And I've remembered one more important step. When we're trying to fix 1-bit errors in subdump, we're just trying to change each bit to opposite. Like, for "001101010101" Q-sector with failed Q-CRC, we're checking the validity of Q-CRC for "101101010101", "011101010101", "000101010101", etc. So you don't need to know the sector type to fix 1-bit Q-channel errors. Not sure if it's effective for 2-bits errors and above (too many variants to check).

10. Does this algo support all SecuROM (at least 4 patterns) and Libcrypt?

Subdump - no, but you can add additional Q-CRC checks for these.

Also I forgot to mention the P and R-W channels fixing. Subdump analyzes the channel and if 7 or more bytes are equal, we define it as a 'padding byte' for this channel of this sector, then we compare 12 bytes of the read sector with the generated sector with all 12 bytes = padding byte, then we compare the difference in bits with the FixLevel value. CD+G channels won't have any 'padding' bytes, so they won't be fixed, just ignored. There are many PSX discs with 0x01, 0x02, 0x03 bytes in R-W, this pattern should be implemented somehow to avoid the unwanted fixes.

914

(3,521 replies, posted in General discussion)

Audio CDs are known to have them as well - http://redump.org/disc/27432/

Why don't you want to improve the subchannels fixing algorithm? I've explained how it should work, maybe worth to discuss it? The root of misdetections is the incorrect fixing and "don't output the suffix except pce" is not a solution, it's a kludge, that will only result in more bad dumps.

915

(3,521 replies, posted in General discussion)

ajshell1 wrote:

So, how exactly do I find that value out? I already dumped it as a CD earlier.

It matches the size of the first track in sectors. Anyway, you need the merged .cue to submit into the db, not .gdi (unless you're trying to make some dumps for your own private use).

iR0b0t wrote:

because FORM2 sectors have no EDC & ECC.

http://www.multimediadirector.com/help/technology/images/gif/cdsectors.gif

917

(3,521 replies, posted in General discussion)

ajshell1 wrote:

I don't think that "[fix]" is supposed to be there.

It should be there, since it only reads the HD area (45000 and above) in DC mode, so it can't know the 2nd track's LBA. You need to dump it again as CD to find out.

918

(4 replies, posted in General discussion)

tossEAC wrote:

When was the data lost, quite some time ago?

http://forum.redump.org/topic/15684/back-from-the-dead/

919

(53 replies, posted in General discussion)

Don't miss the LedZep's tool, he has even posted it a little earlier than sarami - http://forum.redump.org/post/62111/#p62111

920

(57 replies, posted in General discussion)

I mean, is it somehow possible to get that data without using the Kreon-specific "SS extract command"?

921

(57 replies, posted in General discussion)

sarami wrote:
F1ReB4LL wrote:

where is the SS data physically located?

It's in Media Specific area of PFI.

ECMA-267 describes the Control Data Zone as 16 sectors: PFI (2048 bytes), DMI (2048 bytes), CPI (14x2048 bytes). So it belongs to CPI sectors, then?

922

(57 replies, posted in General discussion)

OK. Well, could still be useful for verification dumps using the external SS.bin.

Though, that's an interesting situation if some of the sectors are readable. If these areas are always padded with something (zeroes?), our dumps are bad? smile


Btw, where is the SS data physically located?

http://beta.ivc.no/wiki/index.php/Xbox_ … _game_data -- Between the layers?

https://assemblergames.com/threads/xbox … age.69571/ -- or at the very end of the disc?

Or somewhere in the lead-in? Or around the CMI area?

923

(57 replies, posted in General discussion)

Enker wrote:

I think 0800 drives have a fast error skipping feature, so a normal drive would need to skip the sector ranges in order to dump the discs.

No, you just need a tool that would skip 4096 sectors after each read error.

924

(57 replies, posted in General discussion)

Enker wrote:

For the DVD-DL method, it would need to have the Xbox Layerbreak as well or else the dump would include sectors from the middle zones (zeroes).

Isn't layerbreak standard for all the Xbox discs (1913776)? If yes, some kind of swapdisc image could be created, similar to the DC one.

Security sector range is a problem, but 0800 dumps don't use them, you just count, whether a number of errors is 65536 or not?

925

(57 replies, posted in General discussion)

I mean, I've taken a random DVD-DL disc (larger than 7.3GB), inserted it into the drive, ejected the tray with a pin, swapped with the Xbox disc, closed the tray (basically, what everyone does for dumping DC) and, obviously, all the sectors are reachable. Hasn't anyone ever tried this or that's not enough?