You are supplying what is known as a "crib". If you use a long sequence, especially at the beginning, you are losing some (albeit very little) security.
You can easily mitigate the problem by using a random string, as long as you are able to recover it. For example you might use a 20-byte random string. You know that the first 20 bytes are the delimiter, and look for that in the rest of the string. This still supplies a check for a brute force attacker to determine whether he has found the correct decryption, but the brute force itself should be unwieldy enough that this little help is of almost no use. He still has to decrypt a sizeable portion of the ciphertext before running the test. Compared to only decrypting the crib section, it's an improvement.
You can also use a short, escaped delimiter. Instead of "betting" (with astronomical chances in your favour) that the delimiter will never come up "passively" in the text, you actively endeavour for it to not come up by replacing it or escaping it. For example you can escape all "\" and "|", then decide that a single "|" will represent a delimiter. The chances of a unescaped "|" in a incorrectly decoded ciphertext are astronomical, which makes cribbing worthless for an attacker. At the same time, your escaping naked "|"'s guarantees you that no naked "|"'s will occur in your plaintext. On the other hand this requires one additional stage:
plain|text\nand --> plain\|text\\nand|another text --> ....
If you choose a delimiting character that's usually -escaped, such as maybe $, you can do this with several standard libraries and commands in various languages.
As for security: the random delimiter at the beginning does not decrease security by being at the beginning: since it's random, it cannot be used as a crib. The decrease in security comes from the fact that the delimiter will occur several times in the decrypted text, thereby supplying a confirmation that it is indeed the correctly decrypted text. (If the delimiter is short, chances of it occurring naturally in a incorrect text are not negligible, therefore its occurrence is not a confirmation. And of course its non-occurence can't be a confirmation either). The delimiter has to occur at the beginning because that's the only way you have (the delimiter being random...) of knowing yourself what the delimiter is. Every ciphertext will have its own.
TL;DR unless you have many chunks and/or very short, delimiters are probably the way to go to save space.
In general, you will have enough knowledge of the incoming data to choose an infrequent character as delimiter and as escape character, or at the very least, you will rarely have "pathological" plaintexts. To squeeze to the utmost the data, you can in theory write a function that will (a) determine the two less often used characters in any given plaintext, and (b) use them as delimiter and escape. At most, these characters will occur 3 times every 256 characters. All of them need escaping and will make 256 characters grow to 259, which is a 1.2% increase in size. Also, you will need to store these two characters e.g. at the beginning in order to know how to unescape the string. So we have a fixed overhead of two bytes, a size-overhead of 1.2% and a delimiter overhead of 1:1; if L is the total length of the message and N is the number of chunks, the plaintext thus treated will grow to be 1.012*L+N+2.
Using a delimiter and an unescaped plaintext of length L bytes, the probability of a sequence of length D occurring at position x is (1/256)^D and there are (L-D+1) possible values for x. So the probability of D not occurring anywhere is 1-(1-(1/(256^D)))^(L-D+1).
=(1-POWER((1-POWER(1/256,$D$1)),A2-$D$1+1))*1000000 if you want to get it into a Google spreadsheet and calculate collision probability in millionths).
For a sequence of chunks 16K in size, to be sure to have a Pcoll < 1/million I need at least a delimiter length of 5 (which is overkill; but 4 is too short, giving a Pcoll of around 4/1000000).
So four chunks of 4K each would require 1.012*16384+4+2 = 16586 bytes with escaping and 16384+4*5 without, i.e., delimiters allow a saving of about 182 bytes (with a probability of the delimiter occurring by chance of less than one in a million), and 178 bytes if you use a 6-character delimiter (chances of less than one in a billion, or one thousandth as before).
We hit parity when 1.012*16384+N+2 = 16384+N*5, i.e. when you have more than 50 chunks (or 38 chunks if you use six-char delimiters).
Working in PHP I think you might find it advantageous a sequence like:
- serialize (you obtain a string with all your chunks)
- gzcompress (you save space, and get a maximum-entropy block of data)
Bruteforcing the first AES block will allow verifying whether the decryption key is correct (the beginning of the gzcompressed serialized object may act as a crib), but doing this in the first place (and weeding out the false positives) is still computationally unfeasible. It would still be cheaper to beat the key out of you. And the implementation and maintainability advantages are worthy of the risk.