glennl

Is there a way to turn it off on Windows 10? It keeps the taskbar autohide from hiding.

Yeah, will do some reading on those switches. I've already got a program generating the .ibb and .ibq files, generating a straight-line batch file instead of the .ibq is just a matter of syntax… and error handling... I'll be back if I can't figure something out. Would be handy to add .ibb support to the .ibq files, though... that would be very straightforward to use. Maybe if you think about it some, you'll get an inspiration about how to do it without 3 man-years of work

So since I don't really want the .iso files long term... So I suppose I should figure out where the command line parameters are documented... So if I have to use a batch file, wouldn't it be better just to use the batch file in lieu of a burn queue, and launch ImgBurn once for each CD to burn? Now the burn queue lets me do copies nicely, but I could duplicate the lines in the batch file generated instead... so I could then interleave the burning of .ibb and .cue files in the desired sequence. The question is how to handle errors? Does ImgBurn provide a useful exit code to indicate success/failure to the batch file? And does /start wait for a CD just like the burn queue does between CDs? And I hope /close exits without the "this job is completed" dialog?

P.S. I do know how to make .iso files, and I suppose I could dynamically create them on the fly as a "pre-burn" step so that I could add them to the existing write queue, but since ImgBurn already knows how to burn a collection of files to a CD, why can't it simply use that as a substep in burning a write queue? Granted, I know nothing of the internals of the program, but it seems logically straightforward.

Yep, I figured out I can't do it, but build mode versus write mode I didn't figure out... Those modes may make perfect sense, in some sense, but let's compare some of the use cases: Audio: I can either have a single entry .cue file, and a .bin file, ready to burn, and consume a big chunk of disk space containing duplicates of the .wav files inside the .bin file, or I can have a multi-entry .cue file, and point directly at the .wav files, and be able to access the .wav files with other software, and not need the big chunk of disk space... ImgBurn will just gather together the .wav files and put a big chunk of data on the CD. If I want to burn more than one Audio CD, I can make a write queue, and burn one after another. Data: I can have a .iso file, ready to burn, and consume a big chunk of disk space containing duplicates of the (.mp3, or data files) inside the .iso, or I can have a .ibb file, and be able to access the (.mp3 or data) files with other software, and not need the big chunk of disk space... ImgBurn will just gather together the (.mp3 or data) files and put a big chunk of data on the CD. If i want to burn more than one Data CD, I can ????? Is there a separate write queuet for a sequence of Data CDs? If so, where do I find it? And if so, why is it separate from the Audio CD write queue? And if not, doesn't that sound like a useful feature that is missing?

So I had a bunch of .cue/.bin and .iso files for audio and mp3 files respectively... and had been generating .ibq files to burns sets of them in particular orders. Of course, the .cue/.bin and .iso formats are not directly readable for other purposes, like audio players, so I had another set of directories containing individual tracks. Abhorring the duplication, I finally figured out how to make my own .cue files containing references to individual .wav files, and .ibb files containing references to individual .mp3 files files. All that works. So what doesn't? If I put a .ibb file into the .ibq file, it can't handle it. (invalid image file format error) Is there some particular reason why it can't? (I just tested, and the Write Queue interface won't let me add .ibb files, so I guess I'm breaking the interface by putting one in the .ibq files) It seems like it would be a natural fit to do this. Is there some other write queue format I haven't found that can handle burning a mix of .cue and .ibb files? Or is there a different format than .ibb for the .mp3 files (but that it what it seemed to create when I used the user interface to create one)? Currently using version 2.5.7.0

I found http://forum.imgburn.com/index.php?showtopic=15677&hl=+unicode%20+cue%20+file&do=findComment&comment=122042 which is similar, but Unicode comes in several flavors. I had tried creating a UTF-8 cue file (external to ImgBurn), and it didn't work too well... can't find file names that have Unicode characters. What flavor(s) of Unicode does ImgBurn expect?

So I've figured out how to create CUE files from external software, and I can feed them in and burn a CD... but I can't figure out how to feed in a CUE file and create a BIN file (and maybe it would need a second copy of a CUE file in a different format to correspond), without burning a CD and re-reading it. Am I missing something, or is ImgBurn missing that feature? I'd like to test my CUE files, and the compilations they support, by creating a BIN, mounting it with a CD Emulator, and see how it works before wasting the CDs.

Thanks for the explanation of where the numbers come from. I could reproduce them, but didn't understand them fully. Well, yes, I can see where burning a partial sector would not work. One could speculate about merging multiple tracks prior to burning to avoid leaving unwanted silence for less than a 75th of a second, but it is not clear how useful that would be I did note that the WavTrim application has an option to ensure that the trimmed .wav files in produced are exact sector boundaries, and this also explains its reasoning.

I figured out that if I put a TITLE line at the top of the .cue file, that ImgBurn uses it as Label and Title... but I haven't found anywhere in the interface where I can set that. Presently adding it by hand with Notepad. My program that now generates .cue files can put a TITLE in, too. But for one-off use, I need help to find the UI option for that.

Well, the indentation didn't go through right. One cannot be an expert in the use of every forum. Lines after "with" in the Python source should be indented one more level, folks.

Fiddling around a bit more, I noticed that PREGAP is given in frames that are 75 frames per second. So even though the sample rate is 44100, and not all .wav files are an even multiple of frames, the ImgBurn FILE-DECODED-SIZE seems to be the duration in terms of MM:SS:FF (MM - minutes, SS - seconds, FF - frames at a framerate of 75/second), and any fractional frame is rounded up. Now I can produce exactly the same numbers as ImgBurn. If you have knowledge of why these particular numbers are used, rather than the sample rate or something else, it would satisfy my curiosity. Meantime, I guess I have enough information to do what I need to do, and it is now documented for others that might search. Here's the python source: filename = 'a01.wav' import wave, contextlib with contextlib.closing( wave.open( filename, 'r')) as f: frames = f.getnframes() rate = f.getframerate() framerate = rate / 75 duration = ( frames + framerate -1 ) / framerate frames = duration % 75 secs = ( duration / 75 ) % 60 mins = duration / ( 60 * 75 ) print("%2.2d:%2.2d:%2.2d" % ( mins, secs, frames ))

So the primary answer at http://stackoverflow.com/questions/7833807/get-wav-file-length-or-duration/7842081#7842081 describes a technique for getting the duration of a .wav file in Python, my favorite programming language these days. I note that when adding .wav files to a .cue sheet in ImgBurn, that it produces lines such as: FILE "a01.wav" WAVE REM FILE-DECODED-SIZE 03:04:21 TRACK 01 AUDIO INDEX 01 00:00:00 It seems plausible that the second line of that is ImgBurn's estimate of the audio duration of the .wav file. Yet the Python technique produces 03:04:27 (well, it produces a floating point number of seconds, but I changed the technique slightly to use all integer arithmetic, and produce the MM:SS:HH format output) for that same .wav file. Testing about 10 .wav files, the Python technique always produces a number slightly larger than ImgBurn. How does ImgBurn calculate the duration? Or how is it different than what the Python technique does? Is the REM FILE-DECODED-SIZE actually used by the burn process, or is it ignored, with ImgBurn recalculating the the length from the actual file it is given? I care, because I'm starting to write a program to pull together various sources of metadata, and make my own .cue files to feed to ImgBurn, and I'd like my numbers to match. They are close enough, if ImgBurn ignores the number in the .cue file, of course, as it is within a few hundreths of a second.

So it is. So one more line in the readme.txt would have answered my question! Anyway, this interaction is now in the forum, so findable by the next person that needs to know, if they stumble upon the right search terms (which I think are in this thread's subject line). Thanks for a great program. Until a couple months ago, I used Nero. It is cumbersome, compared to ImgBurn, and not easy to switch from GUI to command line... as best I could figure out, the command line interface they provide could possibly be used to create the same CDs, but they don't document how they translate .nri or .nra files to the command line (if they do), so it is like two completely separate programs to learn, and no sharing of data between them. I've now converted all my processes to use ImgBurn.

Yes, just try that. I tried it. It works great! Not sure how the documentation works as it is forum posts, but can it be updated to include this feature? What is the process for submitting updates?