Jump to content

molecule

Members
  • Posts

    11
  • Joined

  • Last visited

molecule's Achievements

ISF Newbie

ISF Newbie (1/5)

  1. I have several files in different locations on my HDD that I'd like to rename and copy to a single folder on a data-type CD/DVD. On the source HDD the files are stored in different folders. However, for the target CD/DVD, I'd like to gather them under the same folder, with a new folder name. Also I'd like to change names for the new files, only for the target CD/DVD. Names and locations of the source files on the HDD remain unchanged. Does ImgBurn have a ?-project editor (or something like that) where I can do something like that?
  2. completely awesome!! just adding build directory structure to the search database.
  3. ImgBurn IDs CDROM drive for reading CDs, but for writing to CD, it's not in the drop down list doesn't matter if a blank CD is inserted or not entry in ImgBurn log identifies the IDE drive as RAID? I 14:02:16 -> Drive 2 - Info: E-IDE CD -956E/AKV R9HS (H:) (RAID) AMI bios std cmos IDE Master CD-956E/AKV ATAPI CDROM DMA mode=Auto in XPsp3 device mgr device is clear, driver is ID'd as MS 7/1/01 5.1.2535.0 digitally signed driver details cdrom.sys : 5.1.2600.5593 (xpsp_sp3_qfe.080502-1245) imapi.sys, redbook.sys, storprop.dll : 5.1.2600.5512 (xpsp.080413-2108)
  4. just curious ... for computing hash values, are there standard codes or hex strings that I could look for, that would mark the "formal" (arghhh) beginning of a CD file system, and the end of the CD file system inside an iso file that has leading and/or trailing 0x00 padding (that different burners might add for whatever reason ... to make the CD disk more universally compatible with the technology of different CD drives?) would those start codes and end codes occur exactly at the beginning or end of the respective CD sector? --edit2-- or of the 16x or 32x multiple of sectors (depending on media the iso was written to) per the excellent reading CD and writing CD guides on this forum. Since padding is variable, depending on choice of burner or media, it seems like it should be excluded from the hash value? edit1 -- when ImgBurn computes MD5 does it include just the file system within the CD, excluding 0x00 padding added by burners for drive compatibility, or, does it compute hash for the entire CD itself (CD-sector 0 to CD-last sector) including the 0x00 padding? thanks
  5. I understand from this site http://twiki.org/cgi-bin/view/Wikilearn/CdromMd5sumsAfterBurning that some CD burners automatically add 0x00 padding after the End of CD code. Apparently some kernels crash if they can't look ahead or something. So in linux this fellow got his hash values to work consistently by computing hash only from sectors 1 to EOCD by running them through pipes $ dd if=/dev/cdrom | head -c 682575872 | md5sum 1333162+0 records in 1333161+0 records out 7a0479dc917d35bd822cecb558c8d432 one of the patrons at msfn.org got different md5 values from iso files pulled from same cd. Nero and MagicIso gave standard results per internet and google ... ImgBurn gave a different hash result. I assume your iso is exact image of CD, including padding of trailing 0x00s, and he was verifying hash from the pulled ISO. MD5 and SHA1 really belong with other verify functions ... why hide them under page 2 of General Tab, so my suggestion still stands. People will find them quicker under the Verify Tab? (which is a great tab to have!) Also, for some reason unbeknownst to me, but SHA1 seems to be what everybody is using for CDs ... arghhh! they use MD5 for everything else. So, it would be nice if you could add an either-or choice, MD5 or SHA1 to verify. Then the ISO rip could exactly replicate the CD including trailing 0x00s (which some burners apparently add to keep kernel look-ahead from crashing ... I'm actually clueless ... noob here talking) and meanwhile, MD5 and SHA1 could stop computation right at the EOCD marker. edit -- also nice to show results in a small popup called verify hash or something, rather than buried in the log file (it scrolls too fast, not intuitive to look there for verify hash value ...) thanks!
  6. yes, I was thinking Suggestion ... I'm hoping it would probably be a pretty simple to add (total noob here) it would be a nice feature AFAIK ImgBurn would be the first the EZ-mode > Verify page is already setup for it and ready to go under [select source CD drive] section there already is a checkbox for Verify [_] Verify against an image file add two checkboxes under option for compute hash [_] Compute MD5 hash value for this CD [_} Compute SHA1 hash value for this CD I think the exe's are both relatively small and open source ... maybe they could go in the ImgBurn directory? user enters CD, selects hash options, presses the [verify-go] button ImgBurn then opens a popup box with progress bar reads CD, computes the hash(s), and displays results after progress bar and results are displayed the popup offers user options (previously greyed-out) [_] save hash value(s) to file [name...] [browse...] [_] copy hash results to clipboard user can verify CD hash without ripping iso, and finding and running hash exe ... then deleting files to clean hdd, etc. by being the first CD tool to add this, ImgBurn would become the gold standard for CD verification by hash computation ... I think it would be a nice option to add! I'm pretty sure lots of others would also feel the same way. === you mentioned build iso from sectors 0 to (x -1) where x is number of sectors is that what ImbBurn does automatically? IF that's the case, then hash computed on ImgBurn iso should be the hash value for the CD. That's what I wanted to confirm. That the [0 to X-1] should be the standard for computing CD hash values. (I didn't see where I could select start and end points to pull an iso. Don't want to if I don't have to ... just want a hash to verify my hologram CD is not corrupt one. If I gooogle on a valid SHA1, there will be lots of answers ... if google of hash is null, it's a probably a bad CD ...) Also just curious ... any idea what would happen if I hex edited the leading and trailing 0x00's from the iso file, and then tried to burn the iso to CD and run it without leading and trailing 0x00s? Thanks! == ps ... sorry if this is a duplicate post ... I must have done something wrong on the first
  7. It happens that I purchased a MS XP Professional CD that I and others suspect might be irregular. I bought it eyeball-to-eyeball at a big box store. To verify I am comparing SHA1 and MD5 hash values of my ISO with others of known origin, for confirmation that it's genuine. The question is, Is there a gold standard for ripping an ISO, for purposes of computing a hash value for the CD? For hash computation my iso was ripped with ImgBurn ... inspecting the ISO file in HxD editor, there are 32,767 null-bytes (0x00007FFF 0x00's) before the first non-null byte (which starts something like 0x01,C,D,0,0,1 ? from memory so might be wrong) and there are 311,296 null-bytes after the last non-null byte. Are these lead-in and tail-out null-bytes a critical or reproducable part of the rip? How are they computed ... do they change, depending on how they are burned in? ... can there be a gold standard for computing hash values for an ISO of a CD? The leading and trailing nulls might not (or they might!) affect operation. I don't know. But they will affect the computation of hash MD5 and SHA1, possibly making hash comparisions moot. If there's not a gold standard, then ... well, how about it ... let's do it! edit ... for those who are curious, the hash that I get for my XP pro SP3 OEM CD using ImgBurn is Label: GRTMPOEM_EN.ISO Size: 618,065,920 md5: cf044066e4a9193b388f628fa0c1be7e sha1: 2bcaaf437bac27ddf6816b0f415fcef9bd85463f The CD says its XP pro Version 2002 includes SP3. The setup program is however, XP Home, and when installed it looks like, XP Home. But the CD and the COA and the packaging all say XP Professional. I can't find confirmation for the hash values ... so wondering ...
  8. thanks Lightning! Your idea about format /s the VFD drive is good one! (How did I miss it?) NT noob here ... the format.com in windows 2000 formats the VFD just fine, but MS dropped the /s switch, and since they also dropped the sys.com file, there is no way install io.sys etc. 2000 doesn't build a boot floppy like 98 and XP do. You can tell, my mind is still functioning at the level of DOS 1.0 -- LOL Also, poking around I found out that the older oakcdrom, aspicd, etc. drivers were originally designed for EIDE CDROMs. Sometimes they don't see SATA CDROMs even if BIOS tries to have them emulating EIDE. There are several FreeDOS drivers made specifically for SATA CDROMs that have to boot under DOS. Start information is available here http://www.bootablecd.de/FreeDOS/help/en/hhstndrd/base/gcdrom.htm I have a 2.88 ima file, so my next task is to somehow start io.sys on the boot sector. VFD doesn't run in 98se, so I can't go that route. Not really a ImgBurn problem, but thought you might like to know about the DOS driver for SATA CDROMs. Without it (that is, with the older EIDE drivers), what happens is that the CD will apparently boot OK, but then its filesystem will not be recognizable, and so it can't recognize command.com. Or, something like that ...
  9. there are a couple of posts that search for similar solutions ... but with what I am proposing I would be hyjacking their threads problem ... install a multi-FD program (with boot disk plus 2nd, 3rd, ...) to a bootable CD go to http://bootcd.narod.ru/images_e.htm and download .ima image files of blank formatted FDDs. Images range from 1.44, 2.88, 100mb for zip, 700mb for cdroms. http://www.shaneo.com/bootdisks/ has images of bootdisks for all windows systems, but they are all 1.44 .imas so now we have a blank iso big enough to work with (which ImgBurn can burn to CD as bootable, if we can make it bootable) problem ... how to add files to the image and get the two boot files, io.sys and msdos.sys (or whatever), in the right place ... go to Virtual Floppy Disk VFD at http://chitchat.at.infoseek.co.jp/vmware/vfd.html and Virtual Floppy Drive. It's a little bit clunky to use ... there is no intallation, it's just an executable. Expand to any location and start vfdwin.exe. before it can create vfds, the driver needs to load. starting with the [Driver] tab (tab 3), select the driver vfd.sys in the same directory then (.) Manual, then [install] the driver, then [start] the driver. (On vfd shutdown, you need to Uninstall driver, then Stop driver) if you already have two real FDDs installed as A & B, your 2 VFDs can be named M and N or whatever. Starting with tab for [Drive 0], select a drive letter (say M), give it persistent-global scope, then [Open] an image file for editing. Select the 2.88 raw image as the target. Using 2000sp4, I had to use Explorer to reformat the 2.88 target drive to clear off all files. Using ImgBurn, I then made an ima file of the source diskettes, the first being the bootable one. open the ima for the bootable fdd in the tab for [Drive 1] as VFD drive M. first copy the hidden io.sys boot file from the bootable 1.44 source, then save the 2.88 ima. do the same for msdos.sys. Theoretically the disk should be bootable. Then copy the rest of the program files from the remainder of the source FDDs into the 2.88 ima. Burn the 2.88 ima using ImgBurn as follows ... select mode Build ... don't add any files to the file box. On the advanced tab, bootable disk subtab, select Make Image Bootable, select image type 2.88 FD, select the 2.88 ima as the boot image. burn the disk. basically, the config.sys needs to load a cdrom driver and the autoexec needs to label the CDROM, in my case as drive Z config.sys: DEVICE=A:\HIMEM.SYS /TESTMEM:OFF DEVICE=EMM386.EXE NOEMS DEVICEHIGH=A:\ASPICD.SYS /D:ASPICD00 FILES=30 BUFFERS=10 STACKS=9,256 DOS=HIGH,UMB BREAK=ON LASTDRIVE=Z autoexec.bat LOADHIGH A:\MSCDEX.EXE /D:ASPICD00 /L:Z the named files need to be version compatible with io.sys and in this case, in the root dir The CD comes back "half bootable" ... whatever loads is able to produce text (maybe BIOS) it says "NTLDR is missing ... press any key to continue" pressing any key loads from HDD not from the CD. ... any ideas on how to build a bootable CD if I have a 2.88 blank image and the io.sys files?
  10. thanks guys ... just so you know, imgburn worked rock steady ... and clean as a whistle, in a w98se box with mfsn unofficial service pack 2.1. The tasks I tested were pulling an iso file off a bootable CD, compiling a batch of files and folders into an ISO file, and writing an ISO to old CD media (50-something X) using my old and noisy 8X SCSI Yamaha CDRW. A totally insignificant and utterly minor observation for older scsi systems -- after writing to CD, and launching the verfiy stage, with a loaded up SCSI-II (aha2960U) system, which many w2k systems might still use, the eject and reload commands need to have a little pause (how long -- who knows) between tray eject and return -- for example, when doing CD changes by hand, I need to give the devices a little more time for all the communication tasks between PCI bios to SCSI bios to CD device and back again to finish. SCSI-2 communications probably not as steady or as fast as today's direct IDE. Imgburn verified at 2X speed, but on an initial insert imgburn read and ripped a commercially burned CD in my 8x cd-drive at 8-12X -- the problem might also be due to a media mismatch, I am forced to use high speed media (52x?) in my slow speed device because slow media is not so available ...) again thanks to Lightning UK!, and mmalves as well. awesome product ...
  11. I'm trying to pull the 2048 byte boot image file off a daemon-mounted iso, of a bootable CD, and need some help a. I used Imgburn to pull the iso off of a bootable CD (win 2ksp4) > ZRMPOEM_EN.ISO 387,424,256 bytes (the iso contains the boot image file?) b. I used daemon tools to mount that iso file to launch next drive > drive Q: in my case c. I launched Imgburn > Imgburn Log window reports it finds 1 - CD-ROM, 1 -CD-RW and 1 DVD-ROM (N.B. daemon tools is apparently mounting the iso into a DVD-ROM, and I'm using w98se ... BTW thank you!! for including the w98se OS during the compiles ... Imgburn works great!! BTW w98se now reads/writes USBs and NTFS seamlessly -- msfn.org -- and has a hard core following, so I hope you aren't forced to drop it) d. in Imgburn main menu, I selected output > image file; then I selected mode > build e. on the right panel, I brought the advanced tab forward; within the advanced tab, I brought the bootable disk tab forward f. on the left panel, I probably needed to identify a source -- my choices were to browse for a file, or for a folder g. clicking browse-for-a-folder, I chose the daemon drive root, e.g. Q:\, as my source, and then I used the pulldown arrow to select it --- BTW, once I load a bubu file by mistake in the source list (such as the iso file itself), how do get it off the list in the drop down box? Selecting file, new project, empties the visible part of the dropdown list, but all of the old list of noobie bubu files are still in there ... ? --- here's where I'm stuck ... (I tried to upload a screenshot, but the uploader seems to hang forever ... hence all the words) 1. to extract the boot image file from the mounted iso-drive, do I need to create a file first, or just add a name for the destination edit box? any hints? 2. under Options: -- ", do I click Make Image Bootable (I'm not trying to compile a final image or burn a CD -- just extract a boot image file to disk, which obviously needs to be bootable -- so I'm confused.) -- ", if I do click MIB (make boot image bootable?), do I leave emulation as 1.44 floppy? -- ", leave boot image file name blank (since I don't have it yet)? -- ", developer ID? -- ", load segment? -- ", sectors to load (should be 4?) 3. under Extract Boot Image, how do I get the reportedly blue image of a floppy disk to light up? or activate the edit box (for the file name of the extracted boot image)? 4. then, press the big button "Build Image File" aka "Create image file from files/folder"? thanks
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.