I'm going to give this scheme maximum benefit of the doubt. Here's my take on it, with conclusion at the bottom:
We've got a file with 10,000,000 7-bit characters, chosen truly randomly. This means every character should appear, on average, every 128 characters. I'm going to refer to this size as a block below.
I'm also going to assume that you're going to specify a key along the lines of "start at the Yth '>' after the 'Q' after the start of the Nth block and finish at the tenth character", because that would be easy to remember. This means that your password is actually randomly determined, and initially unknown to you. A ten-character password chosen at random like this is actually fairly strong. That's 70 bits of randomness.
The first issue is that for each block of 128 characters, there's roughly a 36% chance that any given character doesn't appear in that block. This multiplies as you add on additional blocks, so there's a roughly 13% chance that a 'Q' doesn't appear in two blocks in a row, and a 0.003% chance that a 'Q' won't appear in 10 blocks in a row. That means that only 1 in 27351 sets of 10 blocks will be missing a 'Q'. However, we have a lot of data! We've got 78125 blocks in this file, so we would expect, on average, to find three such 10-block regions without a 'Q' in our 10 MB file. Things get weird when you're dealing with large numbers.
This means we may have to search quite a ways to find the first Q after the start of the Nth block. There's a low chance of it, but as we've seen, there are likely to be three places in our giant file where we have to search roughly a KB of text (manually!) for a single 'Q'. When you consider that we want not just the first but the Nth '>' after that Q, things quickly get complicated. We might have to search through 1 KB for the Q, and then another 1 KB to find the first '>'.
All this means in practice is that we know your password won't be in the last 150 KB or so of the file, because you can't guarantee that any particular pair of characters will be in there in the order and number required.
It also means that we can calculate a key size. You need five pieces of information to find your password in the file: the starting block, the first character, the number of second characters to count ahead, the second character, and the stop character.
We can specify this as a series of numbers and characters: [ 7685, 'Q', 6, '>' ], which means "Start reading at the 6th '>' after the 'Q' in the 7685th block.
Since there are roughly 78000 blocks you can choose for the starting point, that value has between 16 and 17 bits of randomness. It could be any number between 0 and 78000. For characters, you've got 128 choices in two positions, which is 7 bits of randomness each, or 14 bits total. The second number is tricky. Since we can reasonably expect to count ahead at least 1 KB to find each character, it's probably safe to choose a value less than 64 here. That's only six bits of randomness. So, grand total, your key has ( 16-ish + 14 + 6 ) bits of randomness, which is 36-ish bits. If you vary the length, you could add a few more bits. While not trivial, a typical modern home computer could power through all possible combinations in a couple days.
However, as others have pointed out, this is all largely irrelevant. The file itself only has 10,000,000 possible starting points. That means that the key space is actually significantly smaller than the keys themselves, and you really only have around 23 bits of randomness. What this means in practical terms is that each starting position in the file can be referenced by 16,000 different keys, and, actually, memorizing a starting position is significantly easier than memorizing that key structure. If you use a smaller block, there are even fewer possible combinations.
Conclusion: So yeah, as others have said, this is a bad idea. Use a known strong encryption program using a known strong password. You can come up with a password that's easier to memorize that gives you considerably more protection than this convoluted scheme, and you get the benefit of tried and tested encryption algorithms.
