What exactly happens when you use the 'copy /b' command?

Question

Today, I just discovered I could merge certain files using the copy /b command. In particular, I noticed that when I merged two mp3 files, the VLC player exhibited funny behaviours with the timing:

             

Here, it's quite normal but the first music was getting to an end... then the funny part followed....

                          

Here, the time seek was literally running as it was playing.

On combining pictures or PDF with this technique, I discovered that there will be a correct increase in file size but only the first picture will be displayed.

So my question is: What exactly does the copy /b command do? Is it really meant to be used for merging files or is this a hack?

Answer 1

The /b flag of the copy command treats the files as binary (i.e., a raw stream of meaningless bytes), and copies them byte for byte instead of the default (or the /a) behavior which treats them as lines of text (with end-of-line characters, end-of-files, etc.)

You can merge text files with either the default text behavior or the binary switch, but pretty much any binary file will not work. You cannot simply copy the bytes from two binary files and expect them to work because binary files usually have headers, metadata, data structures, etc. that define the format of the file. If you do a binary copy, you will simply be copying all the bytes as is which ends up putting these structures in places that they should not be, so when you open them, the parsing function will have trouble and see what is essentially corrupt data. Some program will ignore the parts that don’t make sense and simply show what they can (which allows for stereography to work), but some will throw an error and complain that the file is corrupt. The ability to detect corruption depends on the file-type.

As an example, let’s invent a simplified PDF format:

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

As you can see, each file will contain a file-level header with some general information, followed by data blocks for each page containing the page data. If you then take two files, each containing one page and merge them as binary files, you will not be creating one two-page file, but instead one corrupt file that starts out with one page, then has a bunch of junk (the file header makes no sense when the program tries to read page two).

The same thing happens for your MP3s. When you combined them like that, the ID3 tags at the start and/or end of the of the second file are retained, and when the player tries to read the next frame, it is expecting audio data, but is finding the header of the second file which does not match the expected format for audio data, so it doesn’t know what to do. Some players will play the header as audio data (which will likely play as static/noise/pops/etc.), some will cut the sound for until the next correct frame, some may stop playing the song altogether, and some may even crash.

The copy command knows nothing about file-types other than plain-text (and even then, only ASCII text), so only plain-text can be combined correctly with it. Binary files must be combined using an editor that knows how to parse and interpret the contents correctly.

Answer 2

A long time ago in the good old Win ME days I use to simply concatenate video clips. It didn't work all the time but it did work some of the time.

This is an example of the command I used:

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

If the movies where not too big and all the same type, frame rate etc, they usually merged flawlessly. Haven't tried anything like this lately.

Answer 3

In your example, with MP3s, it will probably give weird behaviours because of how MP3s get encoded. For example, the ID3v1 tags are the last 128 bytes of an MP3 (i.e. artist, album, etc). This information is not "playable". When VLC or another media player opens up the MP3, it will (probably) play through the first MP3, act funny for the information, and then possibly play through the rest of the file. I don't have Windows loaded right now, so I can't test for sure.

I would assume this is the same as images and movies; depending how the files are encoded depends how the files will "combine". I imagine this functionality came from the days of DOS when everything was in plain text

Answer 4

It's really quite clear what copy /b does. e.g. copy /b a.txt+b.txt c.txt have a look at c.txt

And You can see what it does from doing copy /? and it tells you.

But what on earth makes you think that if you have two audio files and just combine them into one file, byte by byte, what on earth makes you think that's going to work to produce a playable file without any issue. It might work but there's no reason for you to necessarily think it certainly will.

Suppose there's a thing at the top of an audio file that says " start of audio file ". So now you're going to get the words " start of audio file " occurring twice in the resultant file if you were to just combine them byte for byte. That might lead to an error mightn't it.

Even using copy /b or even copy, to combine two text files might not work. eg what if there's something at the start of the text file, like some bytes to say it's the start(like a UTF-BOM), that should only be at the start. And you don't want that occurring twice.

Answer 5

Regarding the MP3, roughly, what's after the header can all be read as data. There's this game, Sonic 3 in Sega Genesis and another game called Sonic & Knuckles. The Sonic & Knuckles original cartridge had a slot intended to insert other games, but when added Sonic 2 and specially 3, probably the checksum would trigger another set of pointers, the game would behave differently. In early stage of using ROMs, whenever we wanted to put two cartridges to work like it was in the hardware, we used copy /b sonick.bin+sonic3.bin sonic3k.bin. This way, their merge would result in one big single ROM where sonick would have the instruction set (pointers) to make it use sonic3 resources.