You are right about the 14th byte being the length on (some) short notes, like your file 4:
00000000 08 00 12 d6 02 08 00 10 00 1a cf 02 12 1b 54 68 ..............Th
00000010 69 73 20 6e 6f 74 65 20 69 73 20 74 68 65 20 66 is note is the f
00000020 69 72 73 74 20 6f 6e 65 20 1a 10 0a 04 08 00 10 irst one .......
00000030 00 10 00 1a 04 08 00 10 00 28 01 1a 10 0a 04 08 .........(......
However, this is not always the case; in your file 9, which is even shorter, the length, at first glance, is at position 26, with the text after that:
00000000 08 00 12 81 01 08 00 10 00 1a 7b 12 17 d7 90 d7 ..........{.....
00000010 91 d7 90 0a d7 92 d7 93 d7 94 0a 31 32 33 34 35 ...........12345
00000020 36 37 38 39 1a 10 0a 04 08 00 10 00 10 00 1a 04 6789............
and observing closely, you can see that in longer files, the text starts one byte behind that:
00000000 08 00 12 c5 07 08 00 10 00 1a be 07 12 ac 02 49 ...............I
00000010 6e 67 72 65 64 69 65 6e 74 73 20 0a 0a 32 20 63 ngredients ..2 c
The reason for this is that the length is coded in a special format: if the byte has its low order bit clear, then the byte is the length itself. If the high order bit is set, take only the low 7 bits, and prepend the next byte before that. For example, ac 02:
1010 1100 0000 0011 => remove 1st bit from 1st byte and prepend 2nd byte
0000 0011 010 1100 => fill a 0 bit from the left and write in standard nibble notation
0000 0001 1010 1100 => this is 1AC hex, or 428 bytes, which is the length of the note
It seems that the length of the file (minus some header) is encoded in the same way starting at position 11. This explains why file 9 is different: it's the only one short enough to have a length < 0x80 (0x7b), so it needs only one byte here, so everything else is shifted left one byte.
And actually, I guess that the "first glance" was wrong; the real length of note 9 is 23 (hex 17), and it consists of 2 lines of 3 unicode characters each (utf-8? This translates those bytes to hebrew characters, or maybe integers in the same encoding as above, yielding unicode code points), ended with a newline, and it's an unfortunate coincidence that the 0a newline looks like the length byte for the numbers.
So, to extract the text, seek to position 11, read a number which can be 1 or 2 bytes according to above, skip one byte which should be 12, read the length of 1 or 2 bytes, then read the text. Actually, i suspect that bytes 4 and 5 are some integer as well; so maybe you should start with byte 4 and adjust the offsets depending on whether it has bit 8 set or not.
