איך שחזרתי נתונים בפורמט לא ידוע מסרט מגנטי

פרהיסטוריה

בהיותי חובב חומרת רטרו, רכשתי פעם ZX Spectrum+ ממוכר בבריטניה. מצורף למחשב עצמו, קיבלתי מספר קלטות שמע עם משחקים (באריזה המקורית עם הוראות), וכן תוכניות מוקלטות על קלטות ללא סימונים מיוחדים. למרבה ההפתעה, נתוני קסטות בנות 40 שנה היו קריאים היטב והצלחתי להוריד מהם כמעט את כל המשחקים והתוכניות.

עם זאת, בחלק מהקלטות מצאתי הקלטות שברור שלא נעשו על ידי מחשב ZX Spectrum. הם נשמעו אחרת לגמרי ובניגוד להקלטות מהמחשב הנזכר, הם לא התחילו עם מטעין BASIC קצר, שבדרך כלל קיים בהקלטות של כל התוכנות והמשחקים.

במשך זמן מה זה רדף אותי - מאוד רציתי לגלות מה מסתתר בהם. אם אתה יכול לקרוא את אות השמע כרצף של בתים, אתה יכול לחפש תווים או כל דבר שמציין את מקור האות. סוג של רטרו-ארכאולוגיה.

עכשיו, אחרי שהלכתי עד הסוף ומסתכל על התוויות של הקסטות עצמן, אני מחייך כי

התשובה הייתה ממש מול עיניי כל הזמן
על התווית של הקסטה השמאלית מופיע שמו של מחשב ה-TRS-80, וממש מתחת לשם היצרן: "מיוצר על ידי Radio Shack בארה"ב"

(אם אתה רוצה לשמור את התככים עד הסוף, אל תיכנס לספוילר)

השוואה בין אותות שמע

קודם כל, בואו נעשה דיגיטציה של הקלטות האודיו. אתה יכול לשמוע איך זה נשמע:

וכרגיל ההקלטה מהמחשב ZX Spectrum נשמעת:

בשני המקרים, בתחילת ההקלטה יש מה שנקרא טון טייס - צליל באותו תדר (בהקלטה הראשונה הוא קצר מאוד < שנייה אחת, אך ניתן להבחין בו). צליל הפיילוט מאותת למחשב להתכונן לקבלת נתונים. ככלל, כל מחשב מזהה רק את צליל הפיילוט "שלו" לפי צורת האות והתדר שלו.

יש צורך לומר משהו על צורת האות עצמה. לדוגמה, ב-ZX Spectrum צורתו מלבנית:

כאשר מזוהה צליל טייס, ה-ZX Spectrum מציג פסים אדומים וכחולים לסירוגין על גבול המסך כדי לציין שהאות זוהה. טון הפיילוט מסתיים דופק סינכרון, שמאותת למחשב להתחיל לקבל נתונים. הוא מאופיין על ידי משך קצר יותר (בהשוואה לטון הפיילוט ולנתונים הבאים) (ראה איור)

לאחר קבלת דופק הסינכרון, המחשב מתעד כל עלייה/ירידה של האות, ומודד את משך הזמן שלו. אם משך הזמן קטן מגבול מסוים, ביט 1 נכתב לזיכרון, אחרת 0. הביטים נאספים לבייטים והתהליך חוזר על עצמו עד לקבלת N בתים. המספר N נלקח בדרך כלל מהכותרת של הקובץ שהורד. רצף הטעינה הוא כדלקמן:

1. טון טייס
2. כותרת (אורך קבוע), מכילה את גודל הנתונים שהורדת (N), שם הקובץ והסוג
3. טון טייס
4. הנתונים עצמם

כדי לוודא שהנתונים נטענים בצורה נכונה, ה-ZX Spectrum קורא את מה שנקרא בייט זוגיות (Parity byte), אשר מחושב בעת שמירת קובץ על ידי XOR ביצוע XOR של כל הבתים של הנתונים הכתובים. בעת קריאת קובץ, המחשב מחשב את בייט הזוגיות מהנתונים שהתקבלו, ואם התוצאה שונה מהתוצאה שנשמרה, מציג את הודעת השגיאה "R Tape loading error". באופן קפדני, המחשב יכול להנפיק הודעה זו מוקדם יותר אם, בעת הקריאה, הוא לא יכול לזהות דופק (הוחמצה או משך הזמן שלו אינו תואם לגבולות מסוימים)

אז בואו נראה עכשיו איך נראה אות לא ידוע:

זה נימת הפיילוט. צורת האות שונה באופן משמעותי, אך ברור שהאות מורכב מחזרה על פולסים קצרים בתדר מסוים. בתדר דגימה של 44100 הרץ, המרחק בין ה"פסגות" הוא בערך 48 דגימות (שמתאים לתדר של ~918 הרץ). בואו נזכור את הנתון הזה.

כעת נסתכל על קטע הנתונים:

אם מודדים את המרחק בין פולסים בודדים, מתברר שהמרחק בין פולסים "ארוכים" הוא עדיין ~48 דגימות, ובין קצרים - ~24. בהסתכלות קטנה קדימה, אגיד שבסופו של דבר התברר שפולסי "רפרנס" בתדר של 918 הרץ עוקבים ברציפות, מתחילתו ועד סופו של הקובץ. ניתן להניח כי בעת שידור נתונים, אם נתקלים בפולס נוסף בין פולסי הייחוס, אנו מחשיבים אותו כביט 1, אחרת 0.

מה עם דופק הסנכרון? בואו נסתכל על תחילת הנתונים:

צליל הפיילוט מסתיים והנתונים מתחילים מיד. מעט מאוחר יותר, לאחר ניתוח מספר הקלטות אודיו שונות, הצלחנו לגלות שהבייט הראשון של הנתונים הוא תמיד זהה (10100101b, A5h). המחשב עשוי להתחיל לקרוא נתונים לאחר שיקבל אותם.

אתה יכול גם לשים לב להזזה של דופק ההתייחסות הראשון מיד לאחר ה-1 האחרון בבייט הסנכרון. זה התגלה הרבה יותר מאוחר בתהליך הפיתוח של תוכנת זיהוי נתונים, כאשר הנתונים בתחילת הקובץ לא ניתנים לקריאה יציבה.

כעת ננסה לתאר אלגוריתם שיעבד קובץ שמע ויטען נתונים.

טוען נתונים

ראשית, בואו נסתכל על כמה הנחות לשמירה על האלגוריתם פשוט:

1. נשקול רק קבצים בפורמט WAV;
2. קובץ השמע חייב להתחיל בצליל פיילוט ואסור להכיל שתיקה בהתחלה
3. קובץ המקור חייב להיות בעל קצב דגימה של 44100 הרץ. במקרה זה, המרחק בין פעימות הייחוס של 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. בשלב הקודם, יהיה צורך גם לבדוק שדופק הייחוס נמצא בכלל. כלומר, אם פשוט מחפשים את המקסימום, זה לא מבטיח שהדחף קיים בקטע הזה. ביישום האחרון שלי של תוכנית הקריאה, אני בודק את ההבדל בין ערכי המשרעת המקסימלית והמינימלית בקטע, ואם הוא חורג מגבול מסוים, אני סופר את נוכחותו של דחף. השאלה היא גם מה לעשות אם דופק הייחוס לא נמצא. ישנן 2 אפשרויות: או שהנתונים הסתיימו והשתיקה באה לאחר מכן, או שיש לראות בכך שגיאת קריאה. עם זאת, נשמיט זאת כדי לפשט את האלגוריתם;
6. בשלב הבא, עלינו לקבוע את נוכחותו של דופק נתונים (סיביות 0 או 1), לשם כך ניקח את אמצע הקטע (prev_pos;pos) middle_pos שווה ל-middle_pos := (prev_pos+pos)/2 ו בשכונה כלשהי של middle_pos בקטע (middle_pos-8;middle_pos +8) בואו נחשב את המשרעת המקסימלית והמינימלית. אם ההבדל ביניהם הוא יותר מ-10, נכתוב סיביות 1 לתוצאה, אחרת 0. 10 הוא קבוע שמתקבל בניסוי;
7. שמור את המיקום הנוכחי ב-prev_pos (prev_pos := pos)
8. חזור על החל משלב 3 עד שנקרא את הקובץ כולו;
9. יש לשמור את מערך הסיביות המתקבל כקבוצה של בתים. מכיוון שלא לקחנו בחשבון את בייט הסינכרון בעת ​​הקריאה, ייתכן שמספר הסיביות לא יהיה כפולה של 8, וגם היסט הסיביות הנדרש אינו ידוע. ביישום הראשון של האלגוריתם, לא ידעתי על קיומו של בייט הסינכרון ולכן פשוט שמרתי 8 קבצים עם מספר שונה של סיביות אופסט. אחד מהם הכיל נתונים נכונים. באלגוריתם הסופי, אני פשוט מסיר את כל הביטים עד A5h, מה שמאפשר לי לקבל מיד את קובץ הפלט הנכון

אלגוריתם ברובי, למעוניינים
בחרתי ברובי כשפה לכתיבת התוכנית, כי... אני מתכנת עליו רוב הזמן. האפשרות אינה בעלת ביצועים גבוהים, אך המשימה להפוך את מהירות הקריאה למהירה ככל האפשר אינה שווה את זה.

# Используем 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*")

תוצאה

לאחר שניסיתי כמה גרסאות של האלגוריתם והקבועים, התמזל מזלי לקבל משהו מאוד מעניין:

אז, אם לשפוט לפי מחרוזות התווים, יש לנו תוכנית לשרטוט גרפים. עם זאת, אין מילות מפתח בטקסט התוכנית. כל מילות המפתח מקודדות כבתים (כל ערך > 80 שעות). עכשיו אנחנו צריכים לגלות איזה מחשב משנות ה-80 יכול לשמור תוכניות בפורמט הזה.

למעשה, זה מאוד דומה לתוכנית BASIC. מחשב ZX Spectrum מאחסן תוכניות בערך באותו פורמט בזיכרון ושומר תוכניות לקלטת. ליתר בטחון, בדקתי את מילות המפתח מולן שולחן. עם זאת, ברור שהתוצאה הייתה שלילית.

בדקתי גם את מילות המפתח BASIC של Atari, Commodore 64 הפופולריים ועוד כמה מחשבים של אז, עבורם הצלחתי למצוא תיעוד, אך ללא הצלחה – התברר שהידע שלי בסוגי מחשבי הרטרו לא כל כך רחב.

ואז החלטתי ללכת הרשימה, ואז נפל מבטי על שמו של היצרן Radio Shack ועל המחשב TRS-80. אלו השמות שהיו כתובים על התוויות של הקסטות שהיו מונחות על שולחני! לא הכרתי את השמות הללו לפני כן ולא הכרתי את מחשב ה-TRS-80, אז נראה לי ש-Radio Shack היא יצרנית קלטות שמע כמו BASF, Sony או TDK, וה-TRS-80 היה זמן ההשמעה. למה לא?

מחשב Tandy/Radio Shack TRS-80

סביר מאוד שהקלטת האודיו המדוברת, שנתתי כדוגמה בתחילת המאמר, נעשתה על מחשב כזה:

התברר שהמחשב הזה והזנים שלו (דגם I/Model III/Model IV וכו') היו מאוד פופולריים בזמן מסוים (כמובן, לא ברוסיה). ראוי לציין שהמעבד בו השתמשו היה גם Z80. עבור מחשב זה אתה יכול למצוא באינטרנט מידע רב. בשנות ה-80 הופץ מידע מחשב ב כתבי עת. כרגע יש כמה אמולטורים מחשבים לפלטפורמות שונות.

הורדתי את האמולטור trs80gp ובפעם הראשונה הצלחתי לראות איך המחשב הזה עובד. כמובן שהמחשב לא תמך בפלט צבעוני, רזולוציית המסך הייתה רק 128x48 פיקסלים, אבל היו הרחבות ושינויים רבים שיכולים להגדיל את רזולוציית המסך. היו גם אפשרויות רבות למערכות הפעלה למחשב זה ואפשרויות להטמעת שפת ה-BASIC (שבניגוד ל-ZX Spectrum, בחלק מהדגמים אפילו לא "הבזק" ל-ROM וניתן היה לטעון כל אפשרות מתקליטון, בדיוק כמו מערכת ההפעלה עצמה)

גם אני מצאתי תוֹעֶלֶת להמיר הקלטות אודיו לפורמט CAS, הנתמך על ידי אמולטורים, אך משום מה לא ניתן היה לקרוא הקלטות מהקלטות שלי באמצעותם.

לאחר שהבנתי את פורמט קובץ ה-CAS (שהתברר כי הוא רק עותק ביט אחר סיביות של הנתונים מהקלטת שכבר הייתה לי בהישג יד, פרט לכותרת עם נוכחות של בייט סינכרון), עשיתי כמה שינויים בתוכנית שלי והצליח להוציא קובץ CAS עובד שעבד באמולטור (TRS-80 Model III):

עיצבתי את הגרסה העדכנית ביותר של כלי ההמרה עם קביעה אוטומטית של הדופק הראשון והמרחק בין פעימות הפניה כחבילת GEM, קוד המקור זמין בכתובת GitHub.

מסקנה

השביל שעברנו התברר כמסע מרתק אל העבר, ואני שמח שבסופו של דבר מצאתי את התשובה. בין היתר, אני:

• הבנתי את הפורמט לשמירת נתונים ב-ZX Spectrum ולמדתי את שגרות ה-ROM המובנות לשמירת/קריאת נתונים מקלטות שמע
• הכרתי את מחשב ה-TRS-80 והזנים שלו, למדתי את מערכת ההפעלה, הסתכלתי על תוכנות לדוגמה ואפילו הזדמן לי לבצע איתור באגים בקודי מכונה (אחרי הכל, כל הזכרונות של ה-Z80 מוכרים לי)
• כתב כלי עזר מלא להמרת הקלטות אודיו לפורמט CAS, שיכול לקרוא נתונים שאינם מזוהים על ידי הכלי ה"רשמי"

מקור: www.habr.com