This forum software has now been archived into static HTML page (i.e. it does not function as a working forum anymore, so you cannot login.)

In due course a new forum will be available to help support newer CamStudio versions.

Sorry for the inconvenience and thank you for your patience.

Lagarith Corruption - any way to fix?

edited June 2012 in Support
I recorded a bunch of videos with Lagarith Lossless in YV12. I was using a slightly out of date version at the time (1.3.23 I think). Only the top right of the video is visible, the rest is horribly corrupted. It LOOKS like there is valid data in there, just scrambled around. I can't seem to reproduce the corruption when trying to record again.


  • I don't know - try Any Video Converter and see if it will rescue it, or VirtualDub.

    I just made one on using VirtualDub - listed near the bottom.


    This is what the corruption looks like. I have it open in virtualdub, and tried converting it to another format but that didn't fix it.
  • Does it open in VirtualDub distorted like that? Looks like PAL format vs. NTSC can look sometimes to me, where it breaks down a few lines in as the scans go out of sync.

    Any more info?

  • Yes, that is it open in VirtualDub. It opens like that no matter what program. I recorded a bunch of videos over the course of that day, and only one was not distorted like that. Said video was one of the middle ones, no pattern I could see to it.

    Is there some sort of filter I could try in VirtualDub to see if it reconstructs it?
  • I don't know, yet this pattern looks familiar somehow. That's why I thought of the PAL vs NTSC format thing - though that was just my first thought. I've never seen Lagarith cause problems besides being so easy to go overtime (over 2GB in file size) with it, since it is lossless. (I get 9 minutes with audio at 32 bit color and 11 minutes with 16-bit color.)

    No pattern to it? So, you mean it does work sometimes without this anomaly? What could the difference be? What screen dimensions are you capturing? Could it be something like an odd-numbered width or a dimension that it just doesn't like?

    I'll sleep on it and see if I can remember where I've seen this before.

  • I meant with the videos captured that day, all of them were corrupted like that except one, and it wasn't the first/last video taken after starting camstudio up. I made sure not to go over 2GB, I was using YV12 colorspace so I had a bit more time. All videos had the same dimensions, and I know that camstudio compensates for odd sizes by cropping the video capture by a pixel (actually, I think it over-sizes the capture by 1px and then cuts it if needed, but either way it crops it to the right size)

    Maybe you remember seeing this in an older version of Lagarith? I did notice I had been using an older version for some reason, v1.3.23, but again, I couldn't reproduce the problem even on that version of the codec.
  • edited June 2012

    CamStudio does not compensate by cropping in the manner you describe, but it does mess up and frustratingly adds a pixel to certain recording regions depending upon the version you are using - with certain cards on certain operating systems!!! So, don't depend upon CamStudio fixing anything - make certain the sizes are even-numbered right from the get-go.

    This bug has been persistent since 2.5b, and every version we get either the fixed region being what's broken or the window region that's broken - they flip-flop as the fix for one must break the other one. I use Sizer to establish a Window region, and on one version I need to make my sizes 1279X719 to get 1280X720, but on the other version I have to do the same fix to the fixed region option instead, and my Sizer windows must be at the correct size of 1280X720. Maddening! But, your issue seems different according to some hazy recollection in the back of my mind. I'll remember eventually... I'll ask DigiDay what caused it for him, as I think I recall this happening to him when we were working with Lagarith way back when.

  • For what it’s worth....

    I tried quite a few tests with Lagarith v1.3.27 with 2.0 to see if I could replicate the file error shown, and found that I could not, but I was surprised otherwise by what I encountered.

    First, using fairly high motion video in a test area of 848 x 480 , I reached the max 2Gb limit in just 4 min 50 seconds, so this has to be considered a suspect cause of such problems.

    But the surprise (to me anyway) was that, in YUY2 and YV12 modes, CamStudio did indeed change deliberately set odd dimensions to AVI compliant even numbers when using the region setting, and in RGB, it recorded without changing the dimensions, and the result of that was a file which opens properly in Vdub, with no signs of corruption. In fixed region, the program has no trouble with an odd number in RGB, but produces a file creation error in the other two modes.

    I’m guessing that the inconsistency may have something to do with changes made to the Lagarith codec in more recent versions, which may be having an unintended effect in the way that CamStudio runs. At any rate, in all of the files produced, even those with odd number pixels, the files loaded into Virtual Dub with no signs of problems, although one would never want to produce a file like that deliberately.

    So, it looks to me like the codec version used has a problem, or the file size crept over the size limit.

  • edited June 2012

    --Jaw drops to floor-- How does it do that in Lagarith when it won't do it anywhere else???? Must be that the color space determines a different algorithm to be used in computing the width and height??? I wish that would be applied everywhere else!

    Thanks a ton for testing this. I no longer have Lagarith on my new computer, because I've become such an Xvid fanboy that it's all I ever use anymore.

    I really no longer think any lossless codec is worthwhile except in VERY rarified archive-related applications. But it does have its fans, so it would be great if it could be made to work every time.

  • edited June 2012
    I use the lossless codec because others capture at way to low a framerate

    As for the cropping, I've noticed that any codec that REQUIRES a certain dimension restriction seems to get it, my guess is that Lagarith in RGB mode doesn't actually need even-sized capture areas. I've noticed it will SAY it is capturing in some odd number if that's the window size it figures out, but the resulting file is actually sized properly. In the case with the corrupt files I have, they are sized properly (668x500)

    As for version/file size, I was using a slightly older version, but the changelog didn't note any bug fixes related to my issue. I also kept my file sizes under 1.5GB
  • I agree with your assessment of what’s happening with CamStudio actually responding to the limitations of the codec/mode. My reaction is “I didn’t think it could do that!”. I should also clarify that, in my own tests, Cam accurately reported the pixel dimensions as it recorded, whether odd or re-set automatically to even, but that may be a difference in my version of CamStudio. Lagarith is known to have problems related to rounding errors, but since I can’t force it to create a bad file no matter how I misuse it, it’s tough to say that’s the problem here.

    Actually, I think that the fact that Lagarith and CamStudio will produce a viewable video, even after one deliberately throws a wrench into the works as I did, is more of a curse than a blessing. It’s too easy to accidentally slip into another region setting or codec mode without realizing that you may be causing the program to accept and record odd number pixel images, which will appear perfectly normal when viewed, but cause problems further down the road.

    Additionally, those who decide to use Lagarith should keep in mind that, if they later decide to use one of the many free video editors or media players which come with “onboard codecs”, there’s a very good chance that they will not be able to open the files which they create using Lagarith, so there’s a strong possibility that the files will have to be re-encoded anyway. This would be the case with editors like Avidemux and many versions of the VLC media player

    I made static AVIs in every codec/mode combination using your pixel dimensions, and all worked perfectly, both in Vdub and for viewing using MPC (my VLC won’t open them) so I’m tempted to think that the problem has to do with your Lagarith version. If the problem is on the encoder side, I’m afraid those corrupted files you have may be lost. I would try to download a more recent version (decoder) before giving up on them, but at this point, I’d fear the worst.

    As lossless codecs go, Lagarith is a bit slower encoder than Huffyuv, but better than most others.

    I use nothing but Xvid MPEG 4 with CamStudio, During the tests I did with Lagarith, I also did a test MPEG 4 on the same streaming video material and then did a side by side comparison of the two. I can’t see any difference at all in the image quality, and the file size of the Xvid MPEG 4 is a small fraction of the Lagarith file.

  • edited June 2012

    I also use Xvid MPEG 4 exclusively now, and actually, it WON in the input frame-rate tests that came about when coldReactive was performing tests to compare processor priority, and discovered Xvid as the clear winner. DigiDay was using Lagarith for its good capture rate quite a while back, but uses MPEG 4 now, I believe (probably x.264 - I have to ask him. He needs his to work within Premier for editing.)

    Here is coldReactive's test video (I include it in my CamStudio playlist at my YouTube channel - watch at Youtube at 480p.)


  • Well, I’d be shocked if any lossless came close to any MPEG version, but if the notion is that one is (for whatever reason) using a lossless, it’s good to know which is best. After watching that video, I re-checked the charts, and confirmed that Huffyuv is indeed a bit faster than Lagarith, although the video indicates otherwise.

    But, if the premise of high priority is merely to maintain the working characteristics of normal priority under varying conditions, the conclusion reached in the video has little meaning, since any variation would be caused by external elements not “directly” related to the codecs, other than the fact that some codecs are so resource intensive that they might be interfered with by other functions.

    BTW I never use AVC/x264 anywhere - not for capture and not in processing. I’ve done side by side by side tests, and this almost always produces a less desirable result than the other options. Now, if someone were to download one of your tutorials at 480 from Youtube and did some analysis on it, they’d find what they have is an un-packed, x264 processed video which looks pretty darn good, so maybe it’s best to let the “Tube” do it and just download the result(?).

    Anyway, how far OT can we possibly get here. Sorry, but I’m thinking that it looks bad for the corrupted Lagarith files. I do hope they were something that can be recreated with nothing more than a loss of work time.

  • edited June 2012
    With stuff like skype video or google hangouts, there is enough movement that I see no real capture speed / size advantage between Lagarith and huffyuv, except that huffyuv can only do YUY2 and Lagarith can go down to YV12 (for comparing the two I set Lagarith to use YUY2)

    Additionally, I've tried x264, it does create much better compression but runs at about 20% less actual framerate capture.

    I also notice this guy is targeting 60FPS, I'm only targeting 15FPS. I know I can get a bit higher framerate if I up my target to 20 or 25ish, but that GREATLY increases the file size I get.

    At this point I'm pretty resigned that the videos were lost that day - the audio is still there and I probably won't absolutely NEED the captured video, so its not terrible. I'll be keeping an eye out if that happens again.
  • Not to get too far off track here, but we need to keep in mind that the “input frame rate” and FPS are not the same thing. I hadn’t realized from watching that video that he had his frame rate set at 60, till I looked at some of his other Youtube videos. When producing raw AVI, you cannot possibly get perfect sync with a frame rate of 60 or 15, because those numbers do not divide evenly into 1000. The best setting on my computer is 5/200 (5 x 200 = 1000), but only if I am producing a raw AVI, which I rarely do. Most often I convert my AVIs to MPEG2 or MP4, and in that case, the setting I prefer is 5/30, because the only requirement is that the “capture frames every” setting can be evenly divided into 1000 (1000 div by 5 = 200) so I can take the AVI into a video editor and set the “input frame rate” to 200 and the FPS can be locked at 30, which is a good number for media players. Using these methods, the A/V sync will always be perfect, no matter how long the video is. Anyway, the important point is that, for finished AVI s, the capture frames x playback rate must equal exactly 1000.

    When I did my tests with Lagarith, I used 5/200, because none of my editors wants to open Lagarith files, and it worked very well as is. I could have used Vdub in full process mode and made the input change from 5/30 to 200/30, but that would have resulted in a monster size file.

    Terry’s Youtube tutorials are the only ones which contain correct setting information. If it hadn’t been for the good information he supplied, I would never have started using this program again.
    The problem is that his videos are overwhelmed by a huge number of really bad ones, which send unsuspecting users down the wrong path and create a lot of unnecessary confusion.

  • VirtualDub can change the framerate without reprocessing the video at all, so I just change it to 1000/66. I need to open them in VirtualDub anyway because the audio is always off sync (sometimes more than 5 seconds)
  • I haven’t had any luck getting Vdub to change frame rate in direct stream without dropping frames, which causes a loss in sync. Maybe it’s just something about the files I’m producing. Anyway, I really want to wind up with an MPEG 2 or MP4 as a finished product, so I re-code in an editor where I can do other work on the material as well.

    But just to confirm what I understood you to be saying at the top of this thread, you did try running the bad files through Vdub in full processing mode? You would need to do that to get a full re-write of the header and new codec. (If it works, you’d get a good image but upside down).

    Also, you do want to check the “use multi threading” box on the Lagarith configure panel. I found that it makes quite a difference.

  • Dropped frames in direct stream copy? I didn't think that was possible. Weird.

    Yes, I've tried running it through full processing into a different codec. The files themselves don't SEEM corrupt to any decoder (they don't report errors or warnings opening the file) its just the contents themselves are garbled.
  • You both feel free to go as off topic as you like! I'm finding all this quite fascinating! (And thanks for the accolades on my vids, Ken!) :-)

    Search will still find this easily, so staying on-topic isn't extremely important.

Sign In or Register to comment.