Hi @ll,

I conducted a few tests, mostly of them between 10 and 15 minutes and now I have a more clear idea about the issue, that whatever is what you experience, is all the same, just depends what software you use to read the file it will be more sensible to one of the problems or to other.

For me all this started when I tried to get the most quality possible in my recordings, so I increased the frame rating. Today I did the tests with the same game (WarThunder), always in a battle, just changing the frame rate of my recordings, and this are the results:

30 fps -> it never gets a problem. I remember I had this issue very rarely before, but not sure what settings I had. But in the tests conducted today, no one file had this issue.

50 fps -> some of the videos are free of failures, some have the extra unneeded GB at the end of the file, and my opinion is that is related to the real length of the video. Up to 5 or 6 minutes I havent errors. Over that I started to have the problem. GSpot reports exactly the 50 fps.

59,940 -> Similar to 50 fps, just when it fails the amount of unneeded Gb at the end of the file is magnified, duplicating in fact the real size that the file should have. GSpot reports 59,940 fps.

60 -> I havent samples of less than 5 minutes, all of them were between 8 and 16 minutes. All of them have the issue, the amount of unneeded GB duplicates the normal size of the file. GSpot, in all the samples reported a frame rate of 59,999, never 60.

To check that it was not a hardware failure I used 3 different Hard Drives, a very quick internal seagate, a external USB teradisk (but with more speed writing/reading than Bandicam needs) and finally an SSD drive.

Failure was exactly the same. It is related to the time of the record, not the drive where is recorded.

Also I had all units prepared for "performance", never go to sleep to save energy, etc...

The codec used was H264 and Motion JPEG. Same results, depending on how long the video, less than 5 minutes, could be fine, more will have problems.

Again: I could understand if my computer was slower enough to get a jerky video but I cant understand how that will translate in a duplicated size due to unneeded Gb of data (or just void data) at the end of the file.

Edited: Last minute test. All those tests were done with a quality factor of 80. Trying to do one in 30 fps and 100 Q it gave too the same error.
Also, dunno if this is related or not, but sometimes the fps overlay shows up exactly the double fps than really my game is running, recording or not. Checked it vs the internal game fps overlay and with razer fps overlay. And indeed, it is exactly the double figure.

Strange I don't have any of these issues. I often record non stop 45 minutes to an hour. Then edit the video down to 20 minutes. I sometimes drop frames on loading screens of some games but those are always edited out and I can simply pause the recording when its loading. But its all still fully synced up by the end of it when I play it back.

Though I use the MPEG-1 codec as Magix my video editor natively supports it. I sometimes use intel quicksync H.264 and I have been playing around with MP4 recently.

Hi Lemonater47

Well, then is clear that a few here face the same problem and something must be the common factor. May be you have the clue, as you mentioned intel quicksync. So you are on intel processor.

I am in AMD, but the issue is not applicable only to the use of AMD APP as it happens to me too when using other codecs than h.264.

Hi again,

In order to get a solution to this I did carry on digging around the problem, which in my case and with my Bandicam settings uses to appear in videos over 5 minutes, or to say in length, over 4Gb.

I found that the unneeded bytes at the end of the file is just a bug in GSpot, as its own author recognizes in his own words:

I think in this case the "19.7GB unneeded bytes at end of file” is a GSpot bug; I may have fixed it already, but have been so busy I haven't yet had a chance to confirm that, nor consolidate various other fixes & updates and post an updated version.

There's are, or at least were, a lot of 32-bit variables used to store file lengths, and they overflow at 4GB. It's not something that comes up a lot (except for DV), so I hadn't really noticed the problem during a lot of early testing, though I have gotten occasional reports about it.

I shouldn't say "I think" - it's definitely wrong. If GSpot's warning message in the screenshot was correct, the usable part of the file is only 25.7GB - 19.7GB = 6GB, which is much too small for a 2hr 2min DV file. That's why it also came up with much too low a bitrate for DV, in about the same proportion.

Without sound, not to mention the redundant sound in a type 2 DV, that file size should be at least (25Mbps x 122 minutes x 60 secs/min) / (8 bits/byte) which is 22GB right there. Add in the two copies of the soundtrack & misc overhead and 25.7GB is probably just about correct.

I'll be changing all file length related variable in GSpot to 64-bit shortly (that's just a programming change - not something that requires a 64-bit O/S, btw). That'll up the limit to 7,179,869,184 gigabytes which is 1,677,216 terabytes which is 16,384 petabytes which is 16 exabytes. That's 8000 times larger than Google's entire storage capacity which. of course, they use to cache the entire Internet, amongst other things.

So that should get rid of that error for a while, anyway

But knowing that it is a bug in GSpot, still not fixed in the latest edition (hope this time I used the word correctly), doesnt help with the synchrony problem, cause those videos that GSpot wrongly says have unneeded bytes, really have some stuttering problems, lost synchrony, jerkiness,... unless...

Unless Bandicam has exactly the same bug... using 32 bits variables, which cannot address more than 4Gb, so over that point (remember is not exactly 4Gb, but a little over that, exactly 4.294.967.295) Bandicam will carry on recording, but everything could be wrong after that and it would explain all the collateral effects we are getting.