You can split mp3 files every 1000 bytes and stitch them together in random order. Here's what will happen: mp3 comes in mp3 blocks of maybe 100-200 bytes. Each block has a four byte header which describes the format of the block and lets you calculate the length. Chances that random 4 bytes match a header are about 1 in 2000. So a player will skip bytes until it finds what looks like a header. Then it calculates the size of the next block according to the header, checks that there is another header at that position, and then you can be reasonably sure you found two real headers, and the MP3 player will start playing. So you have say 10ms of silence at the start.

Since you stitch together 1000 byte blocks without respecting mp3 blocks, you will quite quickly run into a valid block header, followed by some valid bits, followed by invalid bits. Since the player assumes all the bits in an mp3 block are valid, the output will be rubbish. After that, the player recognises that you have no valid header, will skip to the next valid header, and repeat.

The result is that you have randomly reordered music (which is what you wanted), with silence and random rubbish mixed in. It would be much much better to scan through the file, identify the mp3 blocks, and mix them together anyway you like, to avoid the rubbish noises and silences.

Except... There are mp3 variable length modes. Basically, if your blocks should be say 160 bytes each, and one block is nicely compressible and uses only 130 bytes, then the next block uses the last 30 bytes of the previous block and therefore can use 190 instead of 160 bytes. So many blocks use bytes from the previous block. If this is used then you need to extract all the blocks, and determine which bytes each block really contains (add bytes it uses from the previous block, subtract bytes used from the next block). And then you can rearrange the blocks, and try to recreate them so that each block uses the data bytes it should, as far as you can. This won't be perfect, but better than not doing it.

A simpler way is to take the file, decode it, rearrange it in blocks of say 50 milliseconds, and re-encode the output to mp3. You will have lossy encoding, but nobody will notice in your scrambled music.

You can split mp3 files every 1000 bytes and stitch them together in random order. Here's what will happen: mp3 comes in mp3 blocks of maybe 100-200 bytes. Each block has a four byte header which describes the format of the block and lets you calculate the length. Chances that random 4 bytes match a header are about 1 in 2000. So a player will skip bytes until it finds what looks like a header. Then it calculates the size of the next block according to the header, checks that there is another header at that position, and then you can be reasonably sure you found two real headers, and the MP3 player will start playing. So you have say 10ms of silence at the start.

Since you stitch together 1000 byte blocks without respecting mp3 blocks, you will quite quickly run into a valid block header, followed by some valid bits, followed by invalid bits. Since the player assumes all the bits in an mp3 block are valid, the output will be rubbish. After that, the player recognises that you have no valid header, will skip to the next valid header, and repeat.

The result is that you have randomly reordered music (which is what you wanted), with silence and random rubbish mixed in. It would be much much better to scan through the file, identify the mp3 blocks, and mix them together anyway you like, to avoid the rubbish noises and silences.

Except... There are mp3 variable length modes. Basically, if your blocks should be say 160 bytes each, and one block is nicely compressible and uses only 130 bytes, then the next block uses the last 30 bytes of the previous block and therefore can use 190 instead of 160 bytes. So many blocks use bytes from the previous block. If this is used then you need to extract all the blocks, and determine which bytes each block really contains (add bytes it uses from the previous block, subtract bytes used from the next block). And then you can rearrange the blocks, and try to recreate them so that each block uses the data bytes it should, as far as you can. This won't be perfect, but better than not doing it.

A simpler way is to take the file, decode it, rearrange it in blocks of say 50 milliseconds, and re-encode the output to mp3. You will have lossy encoding, but nobody will notice in your scrambled music.

Do NOT encode small chunks, because each time you do this a random amount of silence is added. An mp3 file is always a whole range of blocks of about 20-25ms. Rearrange the audio signal in memory instead, then encode the complete file. And you cannot just concatenate mp3 files because that will duplicate all the meta information.