Estou fazendo cópias de backup de videogames antigos com CloneCD 5.3.3.0 em meu computador Windows 10 x64 com unidade Samsung SH-S223L.
Um deles é Hellfire para PC (expansão Diablo 1):
- O disco tem um
COMPACT disc DATA STORAGElogotipo - Número de série:
S0011770 - Código SID de fábrica:
IFPI 1218 - Código SID do CD-Master:
IFPI L032 - Data de criação do PVD ISO 9660:
1997-11-18 16:30:00.00
Eu uso oredump.orgRecomendação de perfil 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
Pelo que 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 as .subdiferenças, usei somas de verificação SHA1 e um editor hexadecimal para verificar isso.
Eu carreguei dois .subdumps de arquivoaqui.
Devo mencionar que possuo duas cópias deste disco e o comportamento é idêntico em ambos os discos.
Também descartei várias outras mídias de CD-ROM, às vezes recebo esse comportamento, às vezes o subcanal é consistente entre os dumps.
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 em busca de erros com o KProbe 2 e obtive o seguinte resultado:
Editar:
Parece que a condição do disco e/ou a falta de precisão do drive somada ao fato do subcanal não possuir mecanismo de controle de erros (exceto o canal Q) explica por que recebo .subarquivos diferentes ao despejar a mesma mídia várias vezes.
Devo mencionar que também adquiri uma unidade Plextor PX-712A e consegui obter .subarquivos consistentes em dumps usandoCriador de imagem de disco. Este software utiliza 0xD8instruções em vez de 0xBEinstruções para ler o disco, resultando em imagens mais precisas. Apenas algumas unidades (principalmente Plextor) suportam esta instrução.
Além disso, possuo duas cópias físicas deste CD-ROM que estou descartando (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, obterei .subarquivos consistentes, mas não se eu despejar o primeiro disco e depois o segundo disco.
Acho que está relacionado às condições da mídia, já que uma delas apresenta alguns arranhões e mais erros C1/C2.
Responder1
Os vários formatos de CD são um pouco complicados 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 em 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 trilha espiral de dados de áudio contínuos (o DVD posteriormente usou trilhas circulares). Intercalados nestes dados de áudio de uma forma muito complexa estão 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 propósito original, isso foi suficiente: para reprodução contínua, a lente foi ligeiramente ajustada para seguir a pista. Para buscar, a lente se moveria enquanto decodificava o subcanal Q até que o caminho certo fosse encontrado. Este posicionamento é um pouco grosseiro, mas totalmente adequado para ouvir música.
Ainda hoje, muitas unidades de CD de computador não conseguem posicionar com precisão a lente e sincronizar o circuito de decodificação para que a leitura das amostras de áudio comece em uma posição exata. É por isso que muitos programas de extração de CD têm um modo de "paranóia", onde fazem leituras sobrepostas e comparam os resultados para ajustar esse "jitter". Como parte do fluxo de áudio, o subcanal também está sujeito a jitter, e é por isso que você obtém diferentes arquivos de subcanal ao copiar em uma unidade de CD que não pode ser posicionada com precisão.
Quando a especificação do CD de dados (CD-ROM) foi desenvolvida para estender a especificação do CD-DA, a importância de endereçar e ler os dados com precisão foi reconhecida, então o quadro de áudio de 2352 bytes foi subdividido em 12 bytes de sincronização e 4 bytes de cabeçalho (para o endereço do setor), deixando os 2.336 bytes restantes para dados e um nível adicional de correção de erros. Usando este esquema, os setores podem ser endereçados com exatidão, sem a necessidade de confiar apenas nas informações do canal Q. Portanto, o efeito de jitter não se aplica, você obtém sempre os mesmos dados ao despejar um CD-ROM e nenhuma habilidade adicional no despejo é necessária.
Editarcom mais detalhes:
De acordo comEcma-130, os dados são embaralhados em etapas: 24 bytes constituem umQuadro F1, os bytes de 106 desses quadros são distribuídos em 106Quadros 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 emQuadros F3. O byte extra contém as informações do subcanal (um subcanal para cada posição de bit). Um grupo de 98 quadros F3 é chamado deseção, e os 98 bytes de controle associados contêm dois bytes de sincronização e 96 bytes de dados reais de subcanal. Além disso, o subcanal Q possui 16 bits de correção de erros CRC nesses 96 bits.
A idéia por trás disso é distribuir os dados na superfície do disco de tal maneira que arranhões, sujeira etc. não afetem muitos bits contínuos, de modo que a correção de erros possa recuperar os dados perdidos, desde que os arranhões não sejam muito grande.
Como consequê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 bytes de controle. Todos os modelos de unidades de CD precisam de um tempo diferente para sincronizar em comparação com outros modelos (você pode testar isso lendo de 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, então eles podem começar um pouco mais cedo ou mais tarde e gerar os dados descodificados nem sempre no mesmo byte.
Portanto, quando o programa de extração emite um READ CDcomando (0xBE), ele fornece um comprimento de transferência e um endereço inicial (ou melhor, tempo do canal Q). O drive posiciona a lente, desembaralha os quadros, extrai o canal Q, compara a hora e, quando encontra a hora correta, 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 alterado entre si. É por isso que você vê diferentes arquivos de subcanais do seu ripper.
Dependendo do hardware e das circunstâncias em que a lente é ajustada, é mais ou menos aleatório se a transferência começar algumas amostras antes ou depois. Portanto, o único padrão que você verá nos resultados é que os deslocamentos são múltiplos do comprimento da transferência.
Alguns modelos de unidade possuem hardware preciso que sempre inicia a transferência ao mesmo tempo. O padrão define um bit na página de modo 0x2a ("Capacidades 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 na verdade não o são. (No Linux, você pode usar sg_modeso sg3-utilespacote para ler as páginas do modo, não sei qual ferramenta usar no Windows).
Responder2
De acordo comeste artigo da Wikipédia
Um quadro compreende 33 bytes, dos quais 24 bytes são áudio ou dados do usuário, oito bytes são correção de erros (gerados por CIRC) e um byte é para subcódigo.
Isto sugere que não há correção de erros para o subcanal.
Eu também encontreioutra pergunta em outro lugar. É sobre CDs de áudio, mas acho que resolve o problema certo:
Tudo o que posso dizer é que nunca consegui obter duas leituras de subcanais idênticas (arquivo *.SUB) ao ler do 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 aí:
Apenas os dados de áudio estão sujeitos à 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.
Enquantosujeirapode estar certo emoutra resposta para sua perguntaque você pode não precisar .subde arquivos, 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 possuem correção de erros. Erros de leitura são corrigidos (ou pelo menos detectados) durante a leitura de áudio ou dados 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, não aparecer durante outra, etc. – daí .subos arquivos serem diferentes.
Resposta expandida para abordar o comentário:
Tenho duas cópias deste disco, uma delas em excelente estado (sem arranhões visíveis) e o comportamento ainda é o mesmo. Também tenho outros CD-ROMs de jogos mais antigos em piores condições que possuem
.subarquivos consistentes em vários dumps.
Eu suspeito (infelizmente sem evidências concretas) diferentes CDs podem ter sido fabricados com qualidade diferente. No caso em que os subcanais não importam, o disco de qualidade inferior ainda poderá 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 seu(s) ponto(s) fraco(s) (um bit que fornece leituras inconsistentes) onde a correção de erros pode corrigi-lo; outro acontece que está na área do subcanal.
Um desses bits de subcanal é suficiente para fornecer somas de verificação diferentes, enquanto até mesmo milhares de bits "indecisos" na área de dados do usuário podem ser corrigidos silenciosamente quando necessário, desde que sejam distribuídos o suficiente, de modo que o algoritmo de correção de erros lide com não-muito- muitos deles de cada vez.
Resposta expandida em reação aos resultados do KProbe 2.
Pelo que eu sei, erros C1 são permitidos (em alguma quantidade) porque são corrigidos silenciosamente (mais aqui). Esta correção funciona por causa dos bits de correção de erros. Como eu disse antes, os subcanais não possuem essa redundância em geral (sujeiramenciona correção de erro CRC do subcanal Q, mas isso não muda muito na minha conclusão). Além disso, se o erro ocorrer aí, não há como saber, a menos que você saiba de antemão quais são os dados corretos do subcanal.
Então você teve um total de 1.855 erros que você conhece. Repita o teste (sério, faça isso!) e você poderá ter, por exemplo, 1790 erros; 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, então eu digo que você provavelmente tem cerca de 1855/32 bits de subcanal que foram lidos com erro não detectado. Isso é cerca de 58 bits. Bem, quase, porque graças ao CRC do subcanal 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. Na próxima vez que você ler, poderá obter alguns desses bits sem erros e alguns novos erros de subcanal em outros lugares. Então você obterá .subum arquivo diferente. E ainda assim você não saberá com certeza quais desses bits foram lidos corretamente na primeira ou na segunda vez.