User Activity

  • Created ticket #219 on KDiff3

    character diff not working

  • Created ticket #218 on KDiff3

    editor is not enabled

  • Modified a comment on ticket #81 on cdrtfe

    the data spans fron hub to midele of data area, and writing is either logarithmic or exponential but not linear, so I am expecting that there might be 50GB-100GB more data left to be written on the disc. and it's readable in windows (it's just that windows doesn't have a writeable driver for this kind of disc yet, but it does have a read driver fortunately). very dark brown data side, almost black. the discs are BDR-TL, originally made by Panasonic. I have 2 left. interesting. when I previously used...

  • Posted a comment on ticket #81 on cdrtfe

    it turns out 79,769,098,240 bytes (74.2GB microsoft measurement) has been written. let's say 2/3 of the disc is left to write. if I am guessing right, 4*pi*((30mm-23mm)/2)/(79e9*45mm)*(95mm*100e9)~=117e9 bytes of data total. 45mm at midpoint of data area of 79GB 95mm at midpoint of unused area just throwing a kind of estimate equation at it. but this does not take into account the number of bits in a ring. I have this equation for sale as a copy if you want it. since I don't know spot size V and...

  • Posted a comment on ticket #75 on cdrtfe

    happy to report on 1.5.6.0 it now takes 1-2 hours to burn.

  • Posted a comment on ticket #81 on cdrtfe

    the data spans fron hub to midele of data area, and writing is either logarithmic or exponential but not linear, so I am expecting that there might be 50GB-100GB more data left to be written on the disc. and it's readable in windows (it's just that windows doesn't have a writeable driver for this kind of disc yet, but it does have a read driver fortunately). very dark brown data side, almost black. the discs are BDR-TL, originally made by Panasonic. I have 2 left. interesting. when I previously used...

  • Created ticket #81 on cdrtfe

    bdr-100GB without overburn only writes 50% of disc

  • Posted a comment on ticket #635 on MinGW-w64 - for 32 and 64 bit Windows

    the condition that should cause it is a reverse for loop: #include <cerrno> for (unsigned i=2; errno!=ERANGE; i--) { }

View All

Personal Data

Username:
jmichae3
Joined:
2006-03-15 10:11:04

Projects

Skills

  • No skills entered.

Personal Tools

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks