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:

             Take 1

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

            Take 2              Take 3

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?


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.

  • Nice, VLC plays both mp3 files and even seeks correctly though, only problem is that you don't just want to see the time variations... – Chibueze Opata Jul 25 '12 at 4:08
  • Well like I said, some programs are corrupt-file tolerant. VLC’s parsing algorithm can skip the “corrupt” frames, but because they are not actual frames, it has no way of knowing the correct length, so it jumps around. It’s like if you load the above invented two-page PDF file; the reader would not know how many pages there actually are. Your best bet with MP3s is to strip the tags so that there is only a bunch of audio frames before doing a binary copy. – Synetech Jul 25 '12 at 4:11

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


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.


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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.