Que se passe-t-il exactement lorsque vous utilisez la commande 'copy / b'?

Aujourd'hui, je viens de découvrir que je pouvais fusionner certains fichiers en utilisant la copy /bcommande. En particulier, j'ai remarqué que lorsque j'ai fusionné deux fichiers mp3, le lecteur VLC présentait des comportements amusants avec le timing:

Ici, c'est tout à fait normal mais la première musique touchait à sa fin ... puis la partie drôle a suivi ....

Ici, la recherche de temps fonctionnait littéralement pendant qu'elle jouait.

En combinant des images ou des PDF avec cette technique, j'ai découvert qu'il y aura une augmentation correcte de la taille du fichier mais seule la première image sera affichée.

Ma question est donc la suivante: que fait exactement la copy /bcommande? Est-il vraiment destiné à être utilisé pour fusionner des fichiers ou est-ce un hack?

Le /bdrapeau de la copycommande traite les fichiers comme binaires (c'est-à-dire un flux brut d'octets sans signification) et les copie octet par octet au lieu du /acomportement par défaut (ou du ) qui les traite comme des lignes de texte (avec fin de ligne caractères, fin de fichiers, etc.)

Vous pouvez fusionner des fichiers texte avec le comportement de texte par défaut ou le commutateur binaire, mais à peu près n'importe quel fichier binaire ne fonctionnera pas. Vous ne pouvez pas simplement copier les octets de deux fichiers binaires et vous attendre à ce qu'ils fonctionnent car les fichiers binaires ont généralement des en- têtes , des métadonnées et des structures de données, etc. qui définissent le format du fichier. Si vous effectuez une copie binaire, vous copiez simplement tous les octets tels quels, ce qui finit par mettre ces structures à des endroits où elles ne devraient pas être, donc lorsque vous les ouvrez, la fonction d'analyse aura des problèmes et verra ce qui est essentiellement des données corrompues . Certains programmes ignoreront les parties qui n'ont pas de sens et montreront simplement ce qu'ils peuvent (ce qui permet à la stéréographie de fonctionner), mais certains lanceront une erreur et se plaindront que le fichier est corrompu. La capacité de détecter la corruption dépend du type de fichier.

À titre d'exemple, inventons un format PDF simplifié:

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

Comme vous pouvez le voir, chaque fichier contiendra un en-tête de niveau fichier avec des informations générales, suivi de blocs de données pour chaque page contenant les données de la page. Si vous prenez ensuite deux fichiers, chacun contenant une page et les fusionnez en tant que fichiers binaires, vous ne créerez pas un fichier de deux pages, mais plutôt un fichier corrompu qui commence par une page, puis contient un tas de fichiers indésirables (le fichier l'en-tête n'a aucun sens lorsque le programme essaie de lire la page deux).

La même chose se produit pour vos MP3. Lorsque vous les avez combinés comme ça, les balises ID3 au début et / ou à la fin du deuxième fichier sont conservées, et lorsque le lecteur essaie de lire la trame suivante, il attend des données audio, mais trouve l'en-tête de la deuxième fichier qui ne correspond pas au format attendu pour les données audio, il ne sait donc pas quoi faire. Certains joueurs joueront l'en-tête en tant que données audio (qui joueront probablement en tant que statique / bruit / pop / etc.), certains couperont le son jusqu'à la prochaine image correcte, certains peuvent arrêter complètement la lecture de la chanson, et certains peuvent même planter .

La copycommande ne sait rien sur les types de fichiers autres que le texte brut (et même alors, uniquement le texte ASCII), donc seul le texte brut peut être combiné correctement avec lui. Les fichiers binaires doivent être combinés à l'aide d'un éditeur qui sait analyser et interpréter correctement le contenu.

Dans votre exemple, avec les MP3, cela donnera probablement des comportements étranges en raison de la façon dont les MP3 sont encodés. Par exemple, les balises ID3v1 sont les 128 derniers octets d'un MP3 (c.-à-d. Artiste, album, etc.). Ces informations ne sont pas "jouables". Lorsque VLC ou un autre lecteur multimédia ouvre le MP3, il lira (probablement) le premier MP3, agira de manière amusante pour les informations, puis lira éventuellement le reste du fichier. Je n'ai pas Windows chargé en ce moment, donc je ne peux pas tester avec certitude.

Je suppose que c'est la même chose que les images et les films; en fonction de la façon dont les fichiers sont codés dépend de la façon dont les fichiers «se combinent». J'imagine que cette fonctionnalité est venue du temps de DOS quand tout était en texte brut

Il y a longtemps, au bon vieux temps de Win ME, j'utilisais simplement pour concaténer des clips vidéo. Cela n'a pas fonctionné tout le temps, mais cela a fonctionné une partie du temps.

Voici un exemple de la commande que j'ai utilisée:

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

Si les films n'étaient pas trop gros et de même type, cadence, etc., ils ont généralement fusionné parfaitement. Je n'ai rien essayé de tel récemment.

En ce qui concerne le MP3, en gros, ce qui se trouve après l'en-tête peut être lu comme des données. Il y a ce jeu, Sonic 3 dans Sega Genesis et un autre jeu appelé Sonic & Knuckles. La cartouche d'origine Sonic & Knuckles avait une fente destinée à insérer d'autres jeux, mais lorsqu'elle est ajoutée à Sonic 2 et spécialement à 3, la somme de contrôle déclencherait probablement un autre ensemble de pointeurs, le jeu se comporterait différemment. Au début de l'utilisation des ROM, chaque fois que nous voulions faire fonctionner deux cartouches comme dans le matériel, nous les utilisions copy /b sonick.bin+sonic3.bin sonic3k.bin. De cette façon, leur fusion se traduirait par une grande ROM unique où sonick aurait le jeu d'instructions (pointeurs) pour lui faire utiliser les ressources sonic3.