O subcanal do CD-ROM é diferente ao descarregar o mesmo disco?


14

Estou fazendo cópias de backup de jogos antigos com o CloneCD 5.3.3.0 no meu computador Windows 10 x64 com uma unidade Samsung SH-S223L.

Um deles é o Hellfire para PC (expansão Diablo 1):

  • O disco tem um COMPACT disc DATA STORAGElogotipo
  • Número de série: S0011770
  • Código SID da fábrica: IFPI 1218
  • Código SID do CD-Master: IFPI L032
  • Data de criação do ISO 9660 PVD: 1997-11-18 16:30:00.00

Eu uso a recomendação de perfil do redump.org CloneCD:

[CloneCD ReadPrefs]
ReadSubData=1
RegenerateData=0
ReadSubAudio=1
AbortOnReadError=0
FastErrorSkip=0
ReadSpeedData=8
ReadSpeedAudio=8
IntelligentBadSectorScan=1
SectorSkip=1
NoErrorReport=0
FirstSessionOnly=0
AudioQuality=3

Até onde eu sei, o jogo não tem proteção, mas quando despejo o disco duas vezes, acabo com arquivos de subcanais diferentes ( .sub). Os arquivos .ccde .imgsão idênticos, apenas os .subdiferentes, usei somas de verificação SHA1 e um editor hexadecimal para verificar isso.
Carreguei dois .subarquivos de despejo aqui .
Devo mencionar que possuo duas cópias deste disco e o comportamento é idêntico aos dois discos.

Também despejei várias outras mídias de CD-ROM, às vezes recebo esse comportamento, às vezes, o subcanal é consistente entre despejos.

Qual a explicação desse comportamento?


Editar:

Despejei o mesmo CD-ROM novamente com uma unidade Lite-On iH124-14 e vejo o mesmo comportamento ( .subarquivos diferentes ).
Também verifiquei a mídia quanto a erros no KProbe 2 e obtive o seguinte resultado:

Digitalização KProbe 2 BLER


Editar:

Parece que a condição do disco e / ou a falta de precisão da unidade, além do fato de o subcanal não possuir um mecanismo de controle de erros (exceto o canal Q), explica por que obtenho .subarquivos diferentes ao descarregar o mesmo meio várias vezes.

Devo mencionar que também adquiri uma unidade Plextor PX-712A e consegui obter .subarquivos consistentes em despejos usando o Disc Image Creator . Este software utiliza 0xD8instruções em vez de 0xBEinstruções para ler o disco, resultando em imagens mais precisas. Apenas algumas unidades (principalmente o Plextor) suportam esta instrução.

Na verdade, também possuo duas cópias físicas deste CD-ROM que estou descarregando (mesmo número de série, mesmos códigos IFPI e mesmas informações gravadas a laser). Se eu despejar o mesmo disco várias vezes com o Disc Image Creator, obterá .subarquivos consistentes, mas não se despejar o primeiro disco e depois o segundo.
Eu acho que está relacionado às condições da mídia, já que uma delas tem alguns arranhões e mais erros de C1 / C2.


1
erros de leitura (sujeira, arranhões, não necessariamente erros reais da unidade) podem fazer com que as imagens do CDROM sejam diferentes. as diferenças podem ser tão pequenas quanto alguns bits; Uma diferença de 1 bit é suficiente para que as somas de verificação SHA * / MD5 sejam diferentes.
quixotesca

Respostas:


15

Os vários formatos de CD estão um pouco envolvidos, e as especificações oficiais ("livro vermelho" para CD de áudio, "livro amarelo" para CD de dados) não estão disponíveis gratuitamente. Mas você pode encontrar alguns detalhes nos padrões disponíveis, como o Ecma-130.

O CD de áudio original (também chamado de CD-DA) foi modelado no disco de vinil, o que significa que ele também usa uma faixa espiral de dados de áudio contínuos (o DVD posteriormente usou faixas circulares). Intercalados dentro desses dados de áudio de uma maneira muito complexa, existem 8 subcanais (P a W), dos quais o subcanal Q contém informações de tempo (literalmente em minutos / segundos / frações de segundos) e o número da faixa atual. Para o objetivo original, isso foi suficiente: para reprodução contínua, a lente foi ajustada levemente para seguir a pista. Para procurar, a lente se moveria ao decodificar o sub-canal Q até que o caminho certo fosse encontrado. Esse posicionamento é um pouco grosseiro, mas completamente adequado para ouvir música.

Ainda hoje, muitas unidades de CD de computador não podem posicionar a lente com precisão e sincronizar completamente o circuito de decodificação, de modo que a leitura das amostras de áudio comece na posição exata. É por isso que muitos programas de cópia de CD possuem um modo de "paranóia", onde fazem leituras sobrepostas e comparam os resultados para ajustar esse "tremor". Como parte do fluxo de áudio, o subcanal também está sujeito a instabilidade, e é por isso que você obtém arquivos de subcanais diferentes quando copia uma unidade de CD que não pode ser posicionada com precisão.

Quando a especificação CD de dados (CD-ROM) foi desenvolvida para estender a especificação CD-DA, a importância de endereçar e ler com precisão os dados foi reconhecida; portanto, o quadro de áudio de 2352 bytes foi subdividido em 12 bytes de sincronização e 4 bytes de cabeçalho (por o endereço do setor), deixando os 2336 bytes restantes para dados e um nível adicional de correção de erros. Usando esse esquema, os setores podem ser endereçados exatamente sem precisar confiar apenas nas informações do canal Q. Portanto, o efeito de tremulação não se aplica, você sempre obtém os mesmos dados quando despeja um CD-ROM e nenhuma inteligência adicional no despejo é necessária.

Edite com mais detalhes:

De acordo com o Ecma-130 , os dados são embaralhados em estágios: 24 bytes compõem um quadro F1 , os bytes de 106 desses quadros são distribuídos em 106 quadros F2 , que obtêm 8 bytes extras de correção de erros. Esses quadros, por sua vez, recebem um byte extra ("byte de controle") para transformá-los em quadros F3 . O byte extra contém as informações do sub-canal (um sub-canal para cada posição de bit). Um grupo de 98 quadros F3 é chamado de seção , e os 98 bytes de controle associados contêm dois bytes de sincronização e 96 bytes de dados reais do subcanal. Além disso, o subcanal Q possui 16 bits de correção de erro CRC nesses 96 bits.

A idéia por trás disso é distribuir dados na superfície do disco de maneira que arranhões, sujeira etc. não afetem muitos bits contínuos, portanto a correção de erros pode recuperar os dados perdidos, desde que os arranhões não sejam muito grande.

Como conseqüência, o hardware da unidade de CD precisa ler uma seção completa após reposicionar a lente para descobrir onde ela está no fluxo de dados. A decodificação dos vários estágios é feita pelo hardware, que precisa se sincronizar com os 2 bytes de sincronização no fluxo de controle-byte. Todos os modelos de unidades de CD precisam de uma quantidade de tempo diferente para sincronizar em comparação com outros modelos (você pode testar isso lendo em duas unidades diferentes, se as tiver), dependendo de como o hardware é implementado. Além disso, muitos modelos nem sempre levam exatamente o mesmo tempo para sincronizar, para que possam iniciar um pouco mais cedo ou mais tarde e gerar os dados decodificados nem sempre no mesmo byte.

Portanto, quando o programa de READ CDextração emite um comando (0xBE), ele fornece um comprimento de transferência e um endereço inicial (ou melhor, hora do canal Q). O drive posiciona a lente, decodifica os quadros, extrai o canal Q, compara o tempo e, quando encontra o tempo correto, começa a transferir. Essa transferência nem sempre começa no mesmo byte explicado acima, portanto, o resultado de vários READ CDcomandos pode ser alternado entre si. É por isso que você vê diferentes arquivos de sub-canais do seu estripador.

Dependendo do hardware e das circunstâncias em que a lente é ajustada, é mais ou menos aleatório se a transferência iniciar algumas amostras mais cedo ou mais tarde. Portanto, o único padrão que você verá nos resultados é que os turnos são múltiplos da duração da transferência.

Alguns modelos de unidades têm hardware preciso, que sempre inicia a transferência ao mesmo tempo. O padrão define um pouco na página 0x2a do modo ("Recursos de CD / DVD e página de status mecânico") que indica se esse é o caso, mas a experiência do mundo real mostra que algumas unidades que afirmam ser exatas não são de fato. (No Linux, você pode usar sg_modeso sg3-utilespacote para ler as páginas de modo, não sei qual ferramenta usar no Windows).


Obrigado pela sua resposta, isso me dá um contexto interessante. Entendo que não preciso que o subcanal tenha dados adequados do disco, apenas me pergunto por que o subcanal não é consistente entre os dumps.
1818 Chris

1
Sim, tentei explicar por que o subcanal não é consistente: você envia comandos para o disco para ler dados "brutos", incluindo subcanais, e o posicionamento não é preciso, para que a leitura comece em pontos diferentes. Se você comparar os dados que lê, verá que as partes são apenas trocadas. OTOH, os dados do CD-ROM em si não apresentam esse problema. E você precisa do contexto para entender por que o posicionamento não é exato (embora você precise de ainda mais contexto pelo motivo exato , no qual eu não entrei).
dirkt 19/03/19

Estou interessado em saber o motivo exato, se possível. Eu adicionei um link de download para os .subarquivos na minha pergunta. Comparei-o com um editor hexadecimal e você está certo de que os dados foram alterados, mas não consigo encontrar nenhum padrão óbvio.
19417 Chris

Muito interessante, obrigado. Eu instalei o cygwin, sg3-utils e corri sg_modes. Eu tenho 0x2ana seção "Recursos MM e status mecânico (obsoleto)". Amanhã, receberei uma nova unidade Liteon e testarei novamente para ver se recebo um subcanal consistente nos despejos.
19417 Chris

1
A presença da página de código não significa nada, é preciso procurar o bit certo (o bit 1 do sexto byte, "O fluxo CD-DA é preciso"). Se você tiver duas unidades, pegue um CD de áudio, copie-o nas duas unidades e compare os dados. Você deve ver diferentes deslocamentos onde os dados reais diferentes de zero são iniciados. Você provavelmente também verá deslocamentos diferentes para os arquivos do sub-canal entre as duas unidades.
dirkt

8

De acordo com este artigo da Wikipedia

Um quadro compreende 33 bytes, dos quais 24 bytes são dados de áudio ou usuário, oito bytes são correção de erros (gerados por CIRC) e um byte é para subcódigo.

Isso sugere que não há correção de erros para o sub-canal.

Eu também encontrei outra pergunta em outro lugar . É sobre CDs de áudio, mas acho que ele resolve o problema certo:

Tudo o que posso dizer é que nunca consegui obter duas leituras de subcanais idênticas (arquivo * .SUB) ao ler o mesmo CD-DA / CD-TEXT. Isso é normal ao ler no modo RAW porque os dados não são corrigidos porque o formato CD-DA / CD-TEXT não carrega EDC / ECC em todos os subcanais?

A resposta lá:

Somente os dados de áudio são submetidos à codificação Reed-Solomon (C1 e C2). Os dados do canal de subcódigo (canais P ... W) não estão sujeitos a intercalação ou proteção contra erros.

Embora o dirkt possa estar certo em outra resposta à sua pergunta e que talvez você não precise de .subarquivos, a resposta não aborda explicitamente sua pergunta:

Qual a explicação desse comportamento?

Minha resposta: você obtém .subarquivos diferentes porque os subcanais não têm correção de erros. Os erros de leitura são corrigidos (ou pelo menos detectados) durante a leitura de dados de áudio ou do usuário, mas um erro de leitura pode passar como está quando ocorre no bit do subcanal. Erros específicos devido a arranhões ou poeira podem aparecer durante uma sessão de leitura e não durante outra etc. - portanto, os .subarquivos são diferentes.


Resposta expandida para abordar o comentário:

Eu tenho duas cópias deste disco, uma em excelente estado (sem arranhões visíveis) e o comportamento ainda é o mesmo. Também tenho outros CD-ROMs de jogos mais antigos nas piores condições, com .subarquivos consistentes em vários despejos.

Suspeito (infelizmente sem evidências concretas) que CDs diferentes possam ter sido fabricados com qualidade diferente. Em um caso em que os subcanais não importam, o disco de qualidade inferior ainda pode passar nos testes de qualidade projetados para detectar apenas inconsistência de dados. Ou pode ser simplesmente uma questão probabilística: um disco tem seus pontos fracos (um pouco que fornece leituras inconsistentes) onde a correção de erros pode corrigi-lo; outro acontece tê-lo na área do sub-canal.

Um desses bits do subcanal é suficiente para fornecer somas de verificação diferentes, enquanto até milhares de bits "indecisos" na área de dados do usuário podem ser corrigidos silenciosamente quando necessário, se forem distribuídos o suficiente, de modo que o algoritmo de correção de erros lida com não-muito- muitos deles de cada vez.


Resposta expandida em reação aos resultados do KProbe 2.

Tanto quanto sei, os erros C1 são permitidos (em certa quantidade) porque são silenciosamente corrigidos ( mais aqui ). Essa correção funciona devido a bits de correção de erros. Como eu disse antes, os subcanais não têm essa redundância em geral (o dirkt menciona a correção de erros do CRC do subcanal Q, mas isso não muda muito na minha conclusão). Além disso, se o erro ocorrer, não há como conhecê-lo, a menos que você saiba de antemão quais são os dados corretos do subcanal.

Então você teve um total de 1855 erros que conhece. Repita o teste (sério, faça!) E você pode ter, por exemplo, erros 1790; ou 1892. No entanto, a saída corrigida é a mesma sempre que você lê.

Se houver um bit de subcanal para cada 32 bits de dados, digo que você provavelmente possui cerca de 1855/32 bits de subcanais que foram lidos com erro não detectado. Isso é cerca de 58 bits. Bem, quase porque, graças ao CRC do sub-canal Q, alguns desses erros podem ser detectados pelo menos. Como Q é um dos oito subcanais, estimo que você tenha cerca de 50 bits errados em outros subcanais. Da próxima vez que você ler, poderá obter alguns desses bits sem erros e alguns novos erros de subcanais em outros lugares. Então você receberá um .subarquivo diferente . E ainda assim você não saberá com certeza quais desses bits foram lidos corretamente na primeira ou na segunda vez.


Antes de mais nada, obrigado pela sua resposta, entendo que a condição média deve ser levada em consideração, mas tenho duas cópias deste disco em excelente estado (sem riscos visíveis) e o comportamento ainda é o mesmo. Também tenho outros CD-ROMs de jogos mais antigos nas piores condições, com .subarquivos consistentes em vários despejos. Estou ciente de que não preciso do sub-canal, já que o jogo não está protegido, estou fazendo essa pergunta por curiosidade técnica :).
18717 Chris

1
@Christophe Eu expandi minha resposta.
Kamil Maciorowski

Compreendo. Eu acho que poderia ser interessante ter informações de erro para o meio, pedi uma unidade Liteon iHAS124 e usarei o kprobe2 para verificar isso. Eu deveria ter atualização sobre isso amanhã.
19417 Chris

Eu adicionei o resultado da verificação de erro C1 à minha pergunta, parece ser bom, o máximo é 25.
Chris

1
@Christophe Expandi minha resposta novamente.
Kamil Maciorowski
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.