Что именно происходит, когда вы используете команду «copy / b»?

Сегодня я обнаружил, что могу объединить определенные файлы с помощью copy /bкоманды. В частности, я заметил, что когда я объединил два mp3-файла, проигрыватель VLC показал забавное поведение со временем:

Здесь это вполне нормально, но первая музыка подходила к концу ... потом последовала забавная часть ...

Здесь поиск времени буквально бежал, как он играл.

Объединяя изображения или PDF с этой техникой, я обнаружил, что при правильном увеличении размера файла будет отображаться только первое изображение.

Итак, мой вопрос: что именно делает copy /bкоманда? Это действительно предназначено для объединения файлов или это хак?

/bФлаг из copyкоманды лечит файлы в двоичном виде (т.е. сырой поток бессмысленных байт), и копирует их байт в байт , а не по умолчанию (или /a) поведение , которое рассматривает их как строки текста (с конца-строки символы, конец файла и т. д.)

Вы можете объединить текстовые файлы либо с текстовым поведением по умолчанию, либо с двоичным переключателем, но практически любой двоичный файл не будет работать. Вы не можете просто скопировать байты из двух двоичных файлов и ожидать, что они будут работать, потому что двоичные файлы обычно имеют заголовки , метаданные , структуры данныхи т. д., которые определяют формат файла. Если вы делаете двоичную копию, вы просто будете копировать все байты, как есть, что в итоге приведет к тому, что эти структуры будут размещены в местах, которых не должно быть, поэтому, когда вы откроете их, у функции синтаксического анализа возникнут проблемы, и вы увидите, что по сути поврежденные данные , Некоторые программы игнорируют те части, которые не имеют смысла, и просто показывают, что они могут (что позволяет работать стереография), но некоторые выдают ошибку и жалуются, что файл поврежден. Способность обнаружить повреждение зависит от типа файла.

В качестве примера, давайте изобретем упрощенный формат PDF:

Byte(s)    Meaning
---------------------

File header:
0-1        # of Pages
2-3        Language
4-5        Font
6-EOF      Data (each page encoded separately)

Page data:
0-1        Page number
2-3        # of characters on page
4-#chars   Letters contained on the page

Как видите, каждый файл будет содержать заголовок на уровне файла с некоторой общей информацией, за которой следуют блоки данных для каждой страницы, содержащей данные страницы. Если затем вы берете два файла, каждый из которых содержит одну страницу, и объединяете их в двоичные файлы, вы не будете создавать один двухстраничный файл, а вместо этого один поврежденный файл, который начинается с одной страницы, а затем содержит кучу мусора (файл заголовок не имеет смысла, когда программа пытается прочитать вторую страницу).

То же самое происходит с вашими MP3. Когда вы их так скомбинируете, теги ID3 в начале и / или конце второго файла сохраняются, а когда игрок пытается прочитать следующий кадр, он ожидает аудиоданные, но находит заголовок второй файл, который не соответствует ожидаемому формату для аудиоданных, поэтому он не знает, что делать. Некоторые проигрыватели будут воспроизводить заголовок как аудиоданные (которые, вероятно, будут воспроизводиться как статичные / шумовые / попсовые / и т. Д.), Некоторые будут обрезать звук до следующего правильного кадра, некоторые могут вообще прекратить воспроизведение песни, а некоторые могут даже вылететь. ,

Команда copyничего не знает о типах файлов, кроме обычного текста (и даже тогда, только текста ASCII), поэтому только простой текст может быть правильно скомбинирован с ним. Двоичные файлы должны быть объединены с помощью редактора, который знает, как правильно анализировать и интерпретировать содержимое.

В вашем примере, с MP3, это, вероятно, даст странное поведение из-за того, как MP3 кодируются. Например, теги ID3v1 - это последние 128 байтов MP3 (то есть исполнителя, альбома и т. Д.). Эта информация не является "воспроизводимой". Когда VLC или другой медиаплеер открывает MP3, он (вероятно) будет воспроизводить первый MP3, вести себя забавно для информации, а затем, возможно, воспроизводить оставшуюся часть файла. У меня не загружена Windows сейчас, поэтому я не могу проверить наверняка.

Я бы предположил, что это то же самое, что изображения и фильмы; в зависимости от того, как файлы закодированы, зависит, как файлы будут «объединяться». Я полагаю, эта функциональность пришла со времен DOS, когда все было в простом тексте

Давным-давно в старые добрые времена Win ME я просто объединял видеоклипы. Он не работал все время, но иногда работал.

Это пример команды, которую я использовал:

copy /b movie1.mpg + movie2.mpg + movie3.mpg movie4.mpg

Если фильмы не слишком большие и все одинакового типа, частоты кадров и т. Д., Они обычно сливаются безупречно. В последнее время ничего подобного не пробовал.

Что касается MP3, то примерно то, что после заголовка, может быть прочитано как данные. Есть эта игра, Sonic 3 в Sega Genesis и другая игра под названием Sonic & Knuckles. В оригинальном картридже Sonic & Knuckles был слот, предназначенный для вставки других игр, но при добавлении Sonic 2 и особенно 3, возможно, контрольная сумма вызовет другой набор указателей, игра будет вести себя по-другому. На ранней стадии использования ПЗУ, когда мы хотели, чтобы два картриджа работали так, как это было в аппаратном обеспечении, мы использовали copy /b sonick.bin+sonic3.bin sonic3k.bin. Таким образом, их объединение приведет к одному большому ПЗУ, где sonick будет иметь набор инструкций (указателей), чтобы заставить его использовать ресурсы sonic3.