I was thinking same, but I don't think it's missing header, because neither there is after pause.
RF signals use often preamble, but I don't remember ever seen on IR signals. Some fast pulses as preamble could get filtered out, depending on receiver parameters used.
But yes, it's uncommon that A.C. remote starts shooting data without any "foreplay".
I doubt it would be worth the trouble, but if the OP has an Arduino that runs on an Atmega328P, I have software written specifically to do raw capture of strange IR protocols. It uses no libraries, so you know you are getting everything that's being transmitted. It captures up to 600 bits over a period of two seconds after the beginning transition, which should be long enough even for an air conditioner.
https://github.com/gbhug5a/SimpleIRRaw
At worst, it would only duplicate the info he already has.
The repo also has code to determine the carrier frequency. It uses an IR LED as a poor man's photodiode, so the individual carrier transitions filtered out by the typical IR receiver/demodulator can be measured.
Because the bruce firmware uses the IRRemote library without the option to script nor adding a pause in the "spam all" function and I currently don't have a spare led/parts (apart an arduino) to build a second transmitter.
However to avoid any possible issue I coded an apk for my mobile to brute force all the 256 signals with a 3 seconds delay between one signal and the next with no artifact in the raw data (yes I know you will say that there's no need to run all 256, but I want to try them all).
I will, but I doubt there's a missing signal; when you capture the raw signal with esp32 bit pirate the receiver stays on for all the time and the only captured signal were signal1/9.6ms pause/signal2_copy with no long header/tail, nor any additional data (different keys captured in the same session showed no additional data).
The app on android has 2 keys: power on and power off:
power off sends 0F 99 02 21 0D ?? 05 ?? F0, with ?? ranging from 00 to FF
power on sends 0F 98 42 21 0D ?? 05 ?? F0, with ?? ranging from 00 to FF
During the bruteforce, if I tap the key I can stop it, so I can see the last signal that was sent.
These are 2 examples of the raw data sent from the mobile, captured with the lilygo, they look good to me:
Power off:
type: raw
frequency: 38000
duty_cycle: 0.33
data: 432 408 432 410 430 410 434 408 432 1224 434 1222 432 1224 434 1222 432 1224 434 408 432 408 432 1224 434 1222 432 410 434 408 432 1226 434 408 432 408 432 410 434 408 432 408 432 410 434 1222 432 410 434 408 432 408 432 1224 434 408 432 410 434 406 432 408 432 1224 434 408 432 408 432 410 434 408 432 1226 434 1222 432 408 432 1224 434 408 432 410 434 406 434 408 432 410 434 408 432 408 432 410 434 408 432 408 432 410 434 408 432 408 432 1224 434 408 432 1224 434 408 432 410 430 410 434 408 432 410 434 406 434 408 432 410 434 1222 432 1224 434 1222 432 1224 434 406 434 408 432 410 434 406 434 9590 430 410 434 408 432 410 434 406 434 1222 432 1226 434 1222 432 1226 432 1224 430 410 434 408 432 1226 434 1222 432 410 430 410 434 1222 432 410 434 408 432 408 432 410 434 408 432 410 430 1226 432 408 432 410 434 408 432 1224 434 406 434 408 432 410 434 408 432 1224 430 410 434 408 432 410 434 408 432 1224 430 1226 432 408 432 1224 434 408 432 410 434 408 432 408 430 410 434 408 432 408 432 410 434 408 432 410 430 410 434 408 432 410 434 1222 432 408 432 1226 432 408 432 410 434 408 432 408 432 410 434 408 432 408 432 410 434 1222 432 1224 434 1224 432 1224 434 408 432 410 434 406 434 408 432
Signal_1:
Bin: 000011111001100100000010001000010000110100000000000001010000000011110000
Hex: 0F 99 02 21 0D 00 05 00 F0
Pause: 9.590 ms
Signal_2:
Bin: 000011111001100100000010001000010000110100000000000001010000000011110000
Hex: 0F 99 02 21 0D 00 05 00 F0
Power on:
type: raw
frequency: 38000
duty_cycle: 0.33
data: 430 408 430 410 434 408 432 410 430 1226 432 1224 430 1226 432 1224 430 1226 432 408 432 410 434 1222 432 1224 434 408 432 408 432 410 434 408 432 1224 434 408 432 408 432 410 434 408 432 1224 434 406 434 406 432 410 434 1222 432 408 430 410 434 408 432 410 430 1226 432 408 432 410 434 408 432 408 432 1226 432 1224 430 410 434 1222 432 410 434 408 432 408 432 410 434 408 432 410 430 1226 432 1224 434 406 434 408 432 410 434 406 434 408 432 1226 434 408 432 1224 434 408 432 408 432 410 434 408 432 408 432 410 434 1222 432 1224 434 1222 432 1224 434 1222 432 1226 434 408 432 408 432 410 434 408 432 9590 434 406 434 408 432 410 434 408 432 1222 432 1226 434 1222 434 1222 432 1224 432 410 434 408 436 1222 434 1222 432 410 430 410 434 408 432 410 434 1222 432 408 432 410 434 408 432 408 432 1226 434 408 432 410 434 406 434 1224 430 410 434 408 432 410 430 410 434 1224 432 410 434 408 432 408 432 410 434 1222 432 1224 434 408 432 1224 434 406 434 408 432 410 434 408 432 408 432 410 434 1222 432 1224 434 408 432 408 432 410 434 408 432 408 432 1224 434 408 432 1224 434 408 432 408 432 410 434 408 432 410 434 406 434 1222 432 1224 434 1224 430 1226 432 1224 430 1226 432 408 432 410 434 408 432 408 432
Signal_1:
Bin: 000011111001100001000010001000010000110100000011000001010000001111110000
Hex: 0F 98 42 21 0D 03 05 03 F0
Pause: 9.590 ms
Signal_2:
Bin: 000011111001100001000010001000010000110100000011000001010000001111110000
Hex: 0F 98 42 21 0D 03 05 03 F0
I will test the signals today, fingers crossed ;)
Of course I will! 
I prefer simple logic.
Be aware that your original remote could not even send that kind of sequence since your on/off button is alternating on and off...
yes, I have all the power off signals, and with a separate button the power on signals. No alternating signals
In theory your AC could ignore them because ON-ON-ON... cant arrive at single digit counter steps like 6,5,4...
Edit: I mean OFF-OFF-OFF
Sorry but I don't understand; my theory is that at least one signal is accepted from the ac and I'm simulating 256 signals sent from the transmitter (starting from 00 to FF counter), like if I press 256 times the original remote with a pause of 3 seconds. Why it should ignore the command? My theory is that it will ignore the wrong commands and accept the good one(s).
I said in theory... I meant repeating OFF signal at 1-digit steps is not possible output from original remote.
In practice I don't believe that AC cares what number is sent as far as it does change.
Well, I don't want to suggest solutions that don't involve using Arduino, but have you ever thought about looking for a compatible remote control, or trying one of the many "universal" models like this one (and testing it with your air conditioner, since you can always return it within 15 days if it doesn't work)?
Yes, I took into account a universal remote but:
- I want to understand the signal
- I'm not sure the "universal remote" will be universal for that rhoss
If you're doing it to study the protocol, that's fine by me, although it seemed more of a practical need to be able to control the air conditioner from more than one remote control, rather than a study or academic curiosity (after all, understanding that specific protocol won't do much good for any other project, except to understand how sick the minds of air conditioner designers are 
).
I can tell you I've often dealt with remote controls, even different ones (for example, I made a remote control repeater for Sky decoders, first SkyHD and now SkyQ), but the air conditioner ones are "tricky" based on what you've seen yourself: they send complex packets with all the settings, and at the end I have bought a "compatible" remote and I'm done.
As for "universal" air conditioner remote controls, it's very likely that among the 5,000+ models claiming to be compatible, the coding used for that specific air conditioner is included. I've often seen multiple models and even multiple brands adopt the same protocol (probably to use more or less "standard" chips). So, while I can't guarantee that a certain "universal" model will work for your air conditioner, I'd say there's a good 80% chance it might. After that, you generally have at least 15 days to test it and, if it doesn't work, return it to Amazon and get another one.
Worth to try also in my opinion.
But 5000+ models sounds more like marketing, counting every single variant/re-brand from Gree and Midea probably covers most of that.
Signal that is different on every button press is hard bone for these.
I have been playing with dozens of AC protocols and this is not like most of them. For example I can't see any sense that the "rolling" byte is sent twice.
Probably. But many models (even from different brands) use the same communincation protocol, so the main "unique" item could be the remote model compatibiliy. Even if claiming 5000+ models, IMO the distinct "realistic" emulated remotes are much less than that. I can't imagine more than 1000 different protocols, it sounds useless for manufacturers make a brand new protocol. So I'd give a try with an "universal" protocol (costing a few dollars) and send it back if not working.
and....it finally works!
I'm able to shutdown and power on the AC. I noticed that it's better to be far from the receiver like 3-4 meters away instead of being just under it at 1 meter away pointing it to the receiver.
So the protocol/signals are that described here, no long header or whatsoever, just like 0F as header and F0 as tail.
The counter: need to test better, but it seems it's only a toggle, as it was said by some of you; all my signals were accepted, ex:
power off, 00 counter: accepted
power off, 01 counter: accepted
.... : accepted
power on, 00 counter: accepted
power on, 01 counter: accepted
....: accepted
Moreover with the last power on, let's say with counter 09, a poweroff with counter 00 is accepted.
I can say this because there's an acoustic feedback from the ac when the command is ok.
Now I will map some more buttons on the original remote to be able to build a full custom signal and experiment more on that counter.
Next, I will try to implement this protocol in the available libraries.
Thank you all for your ideas and replies, I appreciated.
danielecr, It's good to hear that you have had some success.
Congratulations.
It's great that you got it working. I wonder if we could do a bit more work on the distance issue, just for future reference.
When you capture the original remote's transmissions, do you get different results when doing this from far away vs close in? If so, which is closer to the "normalized" values?
And speaking of the normalized values, do they also work if far enough away?
Does the original remote also have the distance issue - not working if too close to the aircon? Would the clone remote work close in if you reduce transmit power?
What would be the explanation for why being too close would make it not work? Is the receiver just being swamped by the amplitude of the IR when close in? Of course we don't know what the A/C receiver circuit is, but in the end it has to be some kind of 38KHz carrier detector, and you would think that kind of circuit would be pretty robust, particularly if the duty cycle is only 33%.
Anyway, it's good to know that you can be too close as well as too far away.
I will make more tests in the following days and I will try to reply to all the questions. I will update this post.
Your transmitter VSMY14940 has pretty good radiant intensity and narrow angle. Maybe 1m is below ideal distance for that.
9600 usec can be the header. Typical times for headers:
// Brand Freq Duty HEADER "1" "0" TAIL Bits
{"nec", 38000, 0.33, {1,9000, 0,4500}, {1,560, 0,1690}, {1,560, 0,560}, {1, 560, 0,0}, 32},
{"sony", 40000, 0.33, {1,2400, 0, 600}, {1,1200, 0,600}, {1,600, 0,600}, {0, 0, 0,0}, 32},
{"samsung", 38000, 0.33, {1,4500, 0,4450}, {1,560, 0,1600}, {1,560, 0,560}, {1,8950, 0,0}, 32},
{"lg", 38000, 0.33, {1,8500, 0,4250}, {1,560, 0,1600}, {1,560, 0,560}, {1, 800, 0,0}, 28},
{"lg32", 38000, 0.33, {1,4500, 0,4500}, {1,500, 0,1750}, {1,500, 0,560}, {1,8950, 0,0}, 32},
So you are replaying packets without headers (you replaced them with delay(9600) ) - thats why these packets are ignored. This is what I think :)