It appears that you're calculating the buffer length (which is determined by the second argument of the 'crop') message using the float output (right outlet) of the number~ object. However, in the number~ object's Inspector, you will note that its update interval is every 100 ms. Therefore, it's reasonable to expect that it will not report exactly in sync with your metro and will be off by, on average, about 50 ms. I suggest not using that method of determining the cropping length, or even better, not cropping at all. Why not just set the size of the buffer to be the same as the metro interval, and leave it so?

Thank you very much for your answer Christopher, I checked the number~ object and the minimum i can put is 20ms.It's better but not perfect. The reason i use this method rather than any other is that i want to be able to adjust the buffer size according to my needs. For example record one sound not synchronized, or 2000ms synchronized with metro~ etc...But if i understand what you said, it's not possible, i have to use two different way for the recording.Except if you have an other solution ! Thank you.

As far as I can see, there's no reason to be using the sync output of record~ and the float output of number~ to set the buffer size. You're trying to use the sync output of record~ and some calculations to figure out information that you already know elsewhere in your patch. Instead, just set the buffer size you want, and then start recording. In this example, you can set the duration of the chunk of sound you want to record, then record it -- either using your metro scheme for recording alternate chunks, or just recording independently by sending 1 to the record~ object.

Thanks for the patch, i didn't think to use the metro object to set the buffer size! So now i've two solution. If I want to record something synchronize I can use your method and if i want to set another buffer size (not synchronized) i can use the clocker object.

Thanks again Christopher.

Here is update