¿Qué sucede exactamente cuando usa el comando 'copiar / b'?

Hoy, descubrí que podía fusionar ciertos archivos usando el copy /bcomando. En particular, noté que cuando fusioné dos archivos mp3, el reproductor VLC exhibió comportamientos divertidos con el tiempo:

Aquí, es bastante normal, pero la primera música estaba llegando a su fin ... luego siguió la parte divertida ...

Aquí, la búsqueda del tiempo estaba literalmente corriendo mientras jugaba.

Al combinar imágenes o PDF con esta técnica, descubrí que habrá un aumento correcto en el tamaño del archivo, pero solo se mostrará la primera imagen.

Entonces mi pregunta es: ¿Qué hace exactamente el copy /bcomando? ¿Realmente está destinado a usarse para fusionar archivos o es un hack?

El /bindicador del copycomando trata los archivos como binarios (es decir, un flujo sin procesar de bytes sin sentido) y los copia byte por byte en lugar del /acomportamiento predeterminado (o el ) que los trata como líneas de texto (con final de línea caracteres, fin de archivo, etc.)

Puede fusionar archivos de texto con el comportamiento de texto predeterminado o el modificador binario, pero prácticamente ningún archivo binario no funcionará. No puede simplemente copiar los bytes de dos archivos binarios y esperar que funcionen porque los archivos binarios generalmente tienen encabezados , metadatos , estructuras de datos, etc. que definen el formato del archivo. Si hace una copia binaria, simplemente copiará todos los bytes tal como están, lo que termina colocando estas estructuras en lugares donde no deberían estar, por lo que cuando las abra, la función de análisis tendrá problemas y verá qué son datos esencialmente corruptos. . Algunos programas ignorarán las partes que no tienen sentido y simplemente mostrarán lo que pueden (lo que permite que funcione la estereografía), pero algunos arrojarán un error y se quejarán de que el archivo está dañado. La capacidad de detectar daños depende del tipo de archivo.

Como ejemplo, inventemos un formato PDF simplificado:

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

Como puede ver, cada archivo contendrá un encabezado a nivel de archivo con información general, seguido de bloques de datos para cada página que contenga los datos de la página. Si luego toma dos archivos, cada uno con una página y los combina como archivos binarios, no creará un archivo de dos páginas, sino un archivo corrupto que comienza con una página y luego tiene un montón de basura (el archivo el encabezado no tiene sentido cuando el programa intenta leer la página dos).

Lo mismo sucede con tus MP3. Cuando los combina de esa manera, las etiquetas ID3 al comienzo y / o al final del segundo archivo se retienen, y cuando el reproductor intenta leer el siguiente cuadro, está esperando datos de audio, pero está encontrando el encabezado del segundo archivo que no coincide con el formato esperado para los datos de audio, por lo que no sabe qué hacer. Algunos reproductores reproducirán el encabezado como datos de audio (que probablemente se reproducirán como estático / ruido / pops / etc.), algunos cortarán el sonido hasta el siguiente cuadro correcto, algunos pueden dejar de reproducir la canción por completo, y algunos incluso pueden fallar .

El copycomando no sabe nada sobre los tipos de archivos que no sean texto sin formato (e incluso entonces, solo texto ASCII), por lo que solo el texto sin formato se puede combinar correctamente con él. Los archivos binarios deben combinarse utilizando un editor que sepa cómo analizar e interpretar los contenidos correctamente.

En su ejemplo, con MP3, probablemente dará comportamientos extraños debido a cómo se codifican los MP3. Por ejemplo, las etiquetas ID3v1 son los últimos 128 bytes de un MP3 (es decir, artista, álbum, etc.). Esta información no es "jugable". Cuando VLC u otro reproductor multimedia abre el MP3, (probablemente) reproducirá el primer MP3, actuará de manera divertida para la información y luego posiblemente reproducirá el resto del archivo. No tengo Windows cargado en este momento, así que no puedo probarlo con seguridad.

Supongo que esto es lo mismo que las imágenes y las películas; dependiendo de cómo se codifican los archivos depende de cómo se "combinarán" los archivos. Me imagino que esta funcionalidad vino de los días de DOS cuando todo estaba en texto plano

Hace mucho tiempo, en los viejos tiempos de Win ME, solía simplemente concatenar videoclips. No funcionó todo el tiempo, pero funcionó algunas veces.

Este es un ejemplo del comando que utilicé:

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

Si las películas no eran demasiado grandes y del mismo tipo, velocidad de cuadros, etc., generalmente se fusionaban perfectamente. No he probado nada como esto últimamente.

Con respecto al MP3, aproximadamente, lo que está después del encabezado se puede leer como datos. Existe este juego, Sonic 3 en Sega Genesis y otro juego llamado Sonic & Knuckles. El cartucho original de Sonic & Knuckles tenía una ranura para insertar otros juegos, pero cuando se agrega Sonic 2 y especialmente 3, probablemente la suma de comprobación desencadenaría otro conjunto de punteros, el juego se comportaría de manera diferente. En la etapa inicial de uso de ROM, siempre que queríamos poner dos cartuchos a trabajar como si estuvieran en el hardware, usamos copy /b sonick.bin+sonic3.bin sonic3k.bin. De esta manera, su fusión daría como resultado una gran ROM única en la que sonick tendría el conjunto de instrucciones (punteros) para que use los recursos de sonic3.