자기 테이프에서 알 수 없는 형식의 데이터를 복구하는 방법

선사 시대

복고풍 하드웨어를 좋아하는 저는 한때 영국 판매자로부터 ZX Spectrum+를 구입했습니다. 컴퓨터 자체에는 게임이 포함된 여러 오디오 카세트(지시 사항이 포함된 원래 포장)와 특별한 표시 없이 카세트에 녹음된 프로그램이 포함되어 있습니다. 놀랍게도 40년 된 카세트의 데이터는 잘 읽을 수 있었고 거기에서 거의 모든 게임과 프로그램을 다운로드할 수 있었습니다.

그러나 일부 카세트에서 ZX Spectrum 컴퓨터로 녹음한 것이 분명하지 않은 녹음을 발견했습니다. 그들은 완전히 다르게 들렸으며 언급된 컴퓨터의 녹음과 달리 일반적으로 모든 프로그램과 게임의 녹음에 존재하는 짧은 BASIC 부트로더로 시작되지 않았습니다.

한동안 이것이 나를 괴롭혔습니다. 나는 그 안에 무엇이 숨겨져 있는지 정말로 알고 싶었습니다. 오디오 신호를 일련의 바이트로 읽을 수 있다면 신호의 출처를 나타내는 문자나 모든 것을 찾을 수 있습니다. 일종의 복고풍 고고학.

이제 쭉 가보니 카세트 라벨 자체를 보니 미소가 지어지네요.

답은 쭉 내 눈앞에 있었어
왼쪽 카세트의 라벨에는 TRS-80 컴퓨터 이름이 있고 제조업체 이름 바로 아래에는 "Manufactured by Radio Shack in USA"가 있습니다.

(끝까지 줄거리를 유지하고 싶으신 분은 스포일러에 들어가지 마세요)

오디오 신호 비교

우선, 오디오 녹음을 디지털화해 보겠습니다. 다음과 같은 소리를 들어볼 수 있습니다.

그리고 평소와 같이 ZX Spectrum 컴퓨터의 녹음 소리는 다음과 같습니다.

두 경우 모두 녹음 시작 부분에 소위 파일럿 톤 - 동일한 주파수의 사운드(첫 번째 녹음에서는 1초 미만으로 매우 짧지만 구별할 수 있음). 파일럿 톤은 컴퓨터에 데이터 수신을 준비하라는 신호를 보냅니다. 일반적으로 각 컴퓨터는 신호의 모양과 주파수를 통해 "자체" 파일럿 톤만 인식합니다.

신호 형태 자체에 대해 말할 필요가 있습니다. 예를 들어 ZX 스펙트럼에서는 모양이 직사각형입니다.

파일럿 톤이 감지되면 ZX Spectrum은 화면 테두리에 빨간색과 파란색 막대를 번갈아 표시하여 신호가 인식되었음을 나타냅니다. 파일럿 톤 종료 동기 펄스, 이는 컴퓨터에 데이터 수신을 시작하라는 신호를 보냅니다. (파일럿 톤 및 후속 데이터와 비교하여) 지속 시간이 더 짧은 것이 특징입니다(그림 참조).

동기화 펄스가 수신된 후 컴퓨터는 신호의 각 상승/하강을 기록하여 지속 시간을 측정합니다. 기간이 특정 제한보다 작으면 비트 1이 메모리에 기록되고, 그렇지 않으면 0이 기록됩니다. 비트는 바이트로 수집되고 N 바이트가 수신될 때까지 프로세스가 반복됩니다. 숫자 N은 일반적으로 다운로드한 파일의 헤더에서 가져옵니다. 로딩 순서는 다음과 같습니다.

1. 파일럿 톤
2. 헤더(고정 길이), 다운로드한 데이터의 크기(N), 파일 이름 및 유형이 포함됩니다.
3. 파일럿 톤
4. 데이터 그 자체

데이터가 올바르게 로드되었는지 확인하기 위해 ZX Spectrum은 소위 말하는 패리티 바이트 (패리티 바이트), 쓴 데이터의 모든 바이트를 XOR하여 파일을 저장할 때 계산됩니다. 파일을 읽을 때 컴퓨터는 수신된 데이터에서 패리티 바이트를 계산하고 그 결과가 저장된 것과 다를 경우 "R Tape loading error"라는 오류 메시지를 표시합니다. 엄밀히 말하면 컴퓨터가 읽을 때 펄스를 인식할 수 없는 경우(누락되었거나 지속 시간이 특정 제한에 해당하지 않는 경우) 이 메시지를 더 일찍 발행할 수 있습니다.

이제 알 수 없는 신호가 어떻게 생겼는지 살펴보겠습니다.

이것이 파일럿 톤이다. 신호의 모양은 크게 다르지만 신호가 특정 주파수의 짧은 펄스를 반복하여 구성되어 있음은 분명합니다. 44100Hz의 샘플링 주파수에서 "피크" 사이의 거리는 대략 48개 샘플입니다(이는 주파수 ~918Hz에 해당). 이 수치를 기억해 봅시다.

이제 데이터 조각을 살펴보겠습니다.

개별 펄스 사이의 거리를 측정하면 "긴" 펄스 사이의 거리는 여전히 ~48개 샘플이고, 짧은 펄스 사이는 ~24개입니다. 조금 앞을 내다보면 결국 918Hz 주파수의 "참조" 펄스가 파일의 처음부터 끝까지 계속해서 따른다는 것이 밝혀졌습니다. 데이터를 전송할 때 기준 펄스 사이에 추가 펄스가 발생하면 이를 비트 1로 간주하고 그렇지 않으면 0으로 간주한다고 가정할 수 있습니다.

동기화 펄스는 어떻습니까? 데이터의 시작 부분을 살펴보겠습니다.

파일럿 톤이 종료되고 데이터가 즉시 시작됩니다. 잠시 후, 여러 가지 오디오 녹음을 분석한 후 데이터의 첫 번째 바이트가 항상 동일하다는 사실을 발견할 수 있었습니다(10100101b, A5h). 컴퓨터는 데이터를 수신한 후 데이터 읽기를 시작할 수 있습니다.

또한 동기화 바이트의 마지막 첫 번째 펄스 직후 첫 번째 기준 펄스의 이동에 주의할 수도 있습니다. 한참 후에 데이터 인식 프로그램을 개발하는 과정에서 파일 시작 부분의 데이터를 안정적으로 읽을 수 없는 현상이 발견되었습니다.

이제 오디오 파일을 처리하고 데이터를 로드하는 알고리즘을 설명해 보겠습니다.

데이터 로드

먼저, 알고리즘을 단순하게 유지하기 위한 몇 가지 가정을 살펴보겠습니다.

1. WAV 형식의 파일만 고려합니다.
2. 오디오 파일은 파일럿 톤으로 시작해야 하며 시작 부분에 무음이 포함되어서는 안 됩니다.
3. 소스 파일의 샘플링 속도는 44100Hz여야 합니다. 이 경우 48개 샘플의 기준 펄스 사이의 거리는 이미 결정되어 있으므로 이를 프로그래밍 방식으로 계산할 필요가 없습니다.
4. 샘플 형식은 무엇이든 가능합니다(8/16비트/부동 소수점). 읽을 때 원하는 형식으로 변환할 수 있기 때문입니다.
5. 소스 파일이 진폭으로 정규화되어 결과가 안정화된다고 가정합니다.

읽기 알고리즘은 다음과 같습니다.

1. 파일을 메모리로 읽어들이는 동시에 샘플 형식을 8비트로 변환합니다.
2. 오디오 데이터에서 첫 번째 펄스의 위치를 ​​결정합니다. 이렇게 하려면 최대 진폭을 갖는 샘플 수를 계산해야 합니다. 단순화를 위해 수동으로 한 번 계산하겠습니다. prev_pos 변수에 저장해 보겠습니다.
3. 마지막 펄스 위치에 48을 더합니다. (pos := prev_pos + 48)
4. 위치를 48만큼 증가시킨다고 해서 다음 참조 펄스 위치(테이프 결함, 테이프 드라이브 메커니즘의 불안정한 작동 등)에 도달한다는 보장은 없으므로 펄스 위치의 위치를 ​​조정해야 합니다. 이렇게 하려면 작은 데이터 조각(pos-8;pos+8)을 가져와서 최대 진폭 값을 찾으세요. 최대값에 해당하는 위치가 pos에 저장됩니다. 여기서 8 = 48/6은 실험적으로 얻은 상수로, 이는 정확한 최대값을 결정하고 근처에 있을 수 있는 다른 임펄스에 영향을 미치지 않음을 보장합니다. 매우 나쁜 경우, 즉 펄스 사이의 거리가 48보다 훨씬 작거나 클 경우 펄스에 대한 강제 검색을 구현할 수 있지만 이 기사의 범위 내에서 알고리즘에서는 이에 대해 설명하지 않습니다.
5. 이전 단계에서는 기준 펄스가 전혀 발견되었는지 확인하는 것도 필요합니다. 즉, 단순히 최대값을 찾는다고 해서 이 세그먼트에 충동이 존재한다는 것을 보장할 수는 없습니다. 최근 구현한 읽기 프로그램에서는 세그먼트의 최대 진폭 값과 최소 진폭 값의 차이를 확인하고, 특정 한도를 초과하면 임펄스의 존재 여부를 계산합니다. 문제는 기준 펄스를 찾을 수 없는 경우 어떻게 해야 하는가입니다. 두 가지 옵션이 있습니다. 데이터가 종료되고 침묵이 이어지거나, 이를 읽기 오류로 간주해야 합니다. 그러나 알고리즘을 단순화하기 위해 이를 생략하겠습니다.
6. 다음 단계에서는 데이터 펄스(비트 0 또는 1)의 존재를 확인해야 합니다. 이를 위해 세그먼트의 중간(prev_pos;pos) middle_pos를 middle_pos := (prev_pos+pos)/2와 동일하게 취하고 세그먼트(middle_pos-8;middle_pos +8)의 middle_pos 근처에서 최대 및 최소 진폭을 계산해 보겠습니다. 둘 사이의 차이가 10보다 크면 결과에 비트 1을 쓰고, 그렇지 않으면 0을 씁니다. 10은 실험적으로 얻은 상수입니다.
7. 현재 위치를 prev_pos에 저장합니다. (prev_pos := pos)
8. 전체 파일을 읽을 때까지 3단계부터 반복합니다.
9. 결과 비트 배열은 바이트 집합으로 저장되어야 합니다. 읽을 때 동기화 바이트를 고려하지 않았기 때문에 비트 수가 8의 배수가 아닐 수 있으며 필요한 비트 오프셋도 알 수 없습니다. 첫 번째 알고리즘 구현에서는 동기화 바이트의 존재를 몰랐기 때문에 단순히 오프셋 비트 수가 다른 8개의 파일을 저장했습니다. 그 중 하나에는 올바른 데이터가 포함되어 있었습니다. 최종 알고리즘에서는 A5h까지의 모든 비트를 간단히 제거하여 올바른 출력 파일을 즉시 얻을 수 있습니다.

관심 있는 분들을 위한 Ruby 알고리즘
제가 프로그램 작성 언어로 Ruby를 선택한 이유는... 나는 대부분의 시간을 프로그래밍합니다. 옵션은 고성능은 아니지만 읽기 속도를 최대한 빠르게 만드는 작업은 그만한 가치가 없습니다.

# Используем gem 'wavefile'
require 'wavefile'

reader = WaveFile::Reader.new('input.wav')
samples = []
format = WaveFile::Format.new(:mono, :pcm_8, 44100)

# Читаем WAV файл, конвертируем в формат Mono, 8 bit 
# Массив samples будет состоять из байт со значениями 0-255
reader.each_buffer(10000) do |buffer|
  samples += buffer.convert(format).samples
end

# Позиция первого импульса (вместо 0)
prev_pos = 0
# Расстояние между импульсами
distance = 48
# Значение расстояния для окрестности поиска локального максимума
delta = (distance / 6).floor
# Биты будем сохранять в виде строки из "0" и "1"
bits = ""

loop do
  # Рассчитываем позицию следующего импульса
  pos = prev_pos + distance
  
  # Выходим из цикла если данные закончились 
  break if pos + delta >= samples.size

  # Корректируем позицию pos обнаружением максимума на отрезке [pos - delta;pos + delta]
  (pos - delta..pos + delta).each { |p| pos = p if samples[p] > samples[pos] }

  # Находим середину отрезка [prev_pos;pos]
  middle_pos = ((prev_pos + pos) / 2).floor

  # Берем окрестность в середине 
  sample = samples[middle_pos - delta..middle_pos + delta]

  # Определяем бит как "1" если разница между максимальным и минимальным значением на отрезке превышает 10
  bit = sample.max - sample.min > 10
  bits += bit ? "1" : "0"
end

# Определяем синхро-байт и заменяем все предшествующие биты на 256 бит нулей (согласно спецификации формата) 
bits.gsub! /^[01]*?10100101/, ("0" * 256) + "10100101"

# Сохраняем выходной файл, упаковывая биты в байты
File.write "output.cas", [bits].pack("B*")

결과

알고리즘과 상수의 여러 변형을 시도한 결과 운이 좋게도 매우 흥미로운 것을 얻었습니다.

따라서 문자열로 판단하면 그래프를 그리는 프로그램이 있습니다. 그러나 프로그램 텍스트에는 키워드가 없습니다. 모든 키워드는 바이트로 인코딩됩니다(각 값 > 80h). 이제 우리는 80년대의 어떤 컴퓨터가 이 형식으로 프로그램을 저장할 수 있는지 알아내야 합니다.

실제로 BASIC 프로그램과 매우 유사합니다. ZX Spectrum 컴퓨터는 프로그램을 거의 동일한 형식으로 메모리에 저장하고 프로그램을 테이프에 저장합니다. 혹시나 해서 키워드를 확인해봤는데 테이블. 그러나 결과는 명백히 부정적이었다.

또한 인기 있는 Atari, Commodore 64 및 당시 다른 여러 컴퓨터의 BASIC 키워드를 확인하여 문서를 찾을 수 있었지만 성공하지 못했습니다. 레트로 컴퓨터 유형에 대한 지식이 그리 넓지 않은 것으로 나타났습니다.

그러다가 가기로 결정했어요 목록, 그러다가 제조업체 Radio Shack의 이름과 TRS-80 컴퓨터에 시선이 떨어졌습니다. 내 테이블 위에 놓여 있던 카세트 라벨에 적힌 이름입니다! 예전에는 이런 이름도 모르고 TRS-80 컴퓨터에 익숙하지 않았기 때문에 Radio Shack은 BASF, Sony, TDK 등의 오디오 카세트 제조사이고, 재생시에는 TRS-80이 아닌가 하는 생각이 들었습니다. 왜 안 돼?

컴퓨터 탠디/라디오 판잣집 TRS-80

기사 시작 부분에서 제가 예시로 제시한 문제의 오디오 녹음은 다음과 같은 컴퓨터에서 만들어졌을 가능성이 매우 높습니다.

이 컴퓨터와 그 종류(모델 I/모델 III/모델 IV 등)는 한때 매우 인기가 있었던 것으로 나타났습니다(물론 러시아에서는 아님). 그들이 사용한 프로세서도 Z80이라는 점이 주목할 만하다. 이 컴퓨터의 경우 인터넷에서 찾을 수 있습니다. 많은 정보. 80년대에는 컴퓨터 정보가 유통되었습니다. 잡지. 현재 여러 가지가 있습니다. 에뮬레이터 다양한 플랫폼용 컴퓨터.

에뮬레이터를 다운로드했습니다 trs80gp 그리고 처음으로 나는 이 컴퓨터가 어떻게 작동하는지 볼 수 있었습니다. 물론 컴퓨터는 컬러 출력을 지원하지 않았고 화면 해상도는 128x48 픽셀에 불과했지만 화면 해상도를 높일 수 있는 많은 확장과 수정이 있었습니다. 또한 이 컴퓨터의 운영 체제에 대한 많은 옵션과 BASIC 언어 구현을 위한 옵션이 있었습니다(ZX Spectrum과 달리 일부 모델에서는 ROM에 "플래시"되지도 않았으며 다음과 같이 플로피 디스크에서 모든 옵션을 로드할 수 있음). OS 자체)

나도 찾았어 공익사업 오디오 녹음을 에뮬레이터에서 지원하는 CAS 형식으로 변환했지만 어떤 이유로 내 카세트를 사용하여 녹음을 읽을 수 없었습니다.

CAS 파일 형식(동기화 바이트가 있는 헤더를 제외하고 이미 가지고 있는 테이프의 데이터를 비트 단위로 복사한 것으로 밝혀짐)을 알아낸 후 다음을 만들었습니다. 내 프로그램에 몇 가지 변경 사항을 적용하고 에뮬레이터(TRS-80 Model III)에서 작동하는 CAS 파일을 출력할 수 있었습니다.

나는 첫 번째 펄스와 기준 펄스 사이의 거리를 자동으로 결정하는 변환 유틸리티의 최신 버전을 GEM 패키지로 설계했습니다. 소스 코드는 다음에서 확인할 수 있습니다. 깃허브.

결론

우리가 걸어온 길은 과거로의 매혹적인 여행이었고, 결국 그 답을 찾게 되어 기쁘다. 무엇보다도 나는:

• ZX Spectrum에서 데이터를 저장하는 형식을 파악하고 오디오 카세트에서 데이터를 저장/읽기 위한 내장 ROM 루틴을 연구했습니다.
• 나는 TRS-80 컴퓨터와 그 종류에 대해 알게 되었고, 운영 체제를 연구하고, 샘플 프로그램을 살펴보고, 기계어 코드로 디버깅할 기회도 가졌습니다(결국 Z80 니모닉은 모두 나에게 익숙합니다).
• 오디오 녹음을 "공식" 유틸리티에서 인식되지 않는 데이터를 읽을 수 있는 CAS 형식으로 변환하기 위한 본격적인 유틸리티를 작성했습니다.

출처 : habr.com