All Activity

Yes, something along those lines will work, if, he doesn't use a date/time stamp in that Volume Set Identifier. I just had another idea also. There are 5 fields you can populate with data on the "Labels" tab called "Volume Identifiers". One of them is called "System" so I could just generate a date/time and cut'n'paste into that field. But, reading those fields would only be easy using ImgBurn, I imagine. So.....maybe a text file with the most recent date/time in the root of the DISC as you suggested. Even in the volume label itself if you don't need the full 128 ASCII characters that a UDF label provides. Just kicking around some ideas. Or I could just go old skhool and pickup a sharpie after the burn and....you get the idea!

I don't know this for sure, but I don't think there's any metadata burned to a disc by ImgBurn that tells when it was written. The closest you can probably get is to check the date/time stamps on files on the media and you might get an idea. One thing I do when Building an ISO is put a folder in the root directory with the current date to let me know when it was created.

I'd like to know if the media creation date is stored in the "Volume Set Identifier" by chance and if so, is it a date and time, just a date, and how many characters do I need to convert it to an actual operating system date and time? I know the log file stores enough data to possibly get it from there but let's pretend that got deleted by accident or corrupted. And I wanna get it from the media itself. Is this possible?

Yes, everything is fine and as it should be.

hi sorry english is not my native language so , the log is perfect , i dragged a cue and started to burn and in the log there is SAO so it's perfect for audio cd sao , isn' it? just i remember some software have an option to select dao , sao or tao thanks

Like I said, it's the same thing. That's why the option says DAO/SAO and they aren't 2 different options. No extra session gets opened and you've burnt the disc in one go without any forced gaps. That's DAO. The MMC specs just referred to it as SAO for CD and so that's why the program calls it what it does.

hi i have burned a cue +wavfile and in the log there is write type sao how can i push imgburn to use dao? thanks

Unless you’re creating a CD-Extra disc, there won’t be any additions sessions and so you’ve essentially just burnt in DAO mode. So that would be the standard method of burning an audio cd in ImgBurn anyway. If you want control over the gaps between tracks, you just need to avoid TAO.

Hi but when i burn an audio cd , imgburn does it perform always a sao burning i have always read disc at once should be the best for audio cd is there a way to push imgburn to use dao (disk at once) ? thanks

I think where I live, the US, it's a year.

24 months on most electronics, at least in my part of Europe.

I'm pretty sure you only get a 12 month guarantee on most electronics.

I hope it was still in guarantee.

Of course, right after I praised the ASUS for going strong for 1.5 years, I had to replace it Sunday night. So, it lasts for about 18 months with rigorous near daily use before it needed replacing. It developed an issue with its red laser.

Well, I stand corrected. My external USB blu ray burner Verbatim 43889 that I bought in 2023 is a Pioneer drive. But the drive that I bought several days ago - same Verbatim 43889 BD burner - is actually an LG drive :( I guess it's ok for single layer BD's, but I wouldn't trust it with double or triple layer Blu ray discs.

In order to look more like Explorer, the program will now round up rather than doing bankers rounding. So a 0 byte file will show 0 KiB but a 1 byte file will show 1 KiB. A 1024 byte file will show 1 KiB but a 1025 byte file will show 2 KiB.

Good God, I just checked the file again in Windows File Explorer on Windows 10 and it reported the 71 byte file in 3 different sizes. In the "Preview Pane" when the file is selected it reports the size exactly as 71 bytes. In the File Explorer "Size" column it reports as 1K. And when you right-click the file and select the "Properties" dialog box it reports the size correctly at 71 bytes but it reports "Size on disk" as 0 bytes. It's serving up a little bit of everything I guess.

It uses Bankers rounding for all of that stuff. The top pane is a component and its code basically seems to return 1KB if it's anything less than 1. Explorer must be rounding up as it calls a 1025 byte file 2KB.

Possibly, but the way I look at it, if it displays properly 1) immediately after added and 2) no issues displaying 1kb versus 0kb in the top pane, then it's more than likely just a rare bug. Much like the mismatched icons issue I reported months ago. Things start out right, so, and then later on, you wake up your PC or load a saved project back into memory and then go "Huh?". So, I can't see it being a limitation of any existing API outside the programmers control. But well let him inform us all. He knows best.

I would agree that 1 KB/KiB should be returned for files that are actually less than 1. I can see how 0 could lead to some confusion. The only problem I see is that/those components of ImgBurn might be enslaved to standards that Microsoft set. Or however made the programming package that ImgBurn is written in. Those components that return directory contents may be standardized by the programming language and beyond the control of LUK to do anything about.

I'm not sure if this would be called a bug but I believe it is and it needs to be addressed. I burned some very small files to BD-R at less than 100 bytes a file. The bottom DLE pane shows this as being 0 KiB in size while the top pane shows the same files as being 1 KiB in size. Now, we all know neither of these is 100% accurate. But when I just noticed this issue this morning it scared me. So, I went back to look at the file sizes on the actual finished product, the mastered BD-R and the files were burned properly. I thought something may have gone wrong. And lastly, this issue was observed after loading "Most Recent Project" so, while the file sizes may have been reported accurately before the save/load cycle they aren't reported properly afterwards. Small bug, should be really easy fix. But my recommendation is to round up versus rounding down even on files so small. Thanks for reading!

Interesting that this bug seems to be so elusive for everybody except me. I'm on Windows 10 and I do leave ImgBurn running for hours and days just because, I can. So, maybe it's having it loaded and then Windows going to sleep/waking up/rinse/repeat? I dunno but it would be cool just to see it fixed. So, it's wonderful news to hear a fix is coming. I'm preparing to burn another BD-R disc soon and this same issue led me back to this website several months later to see if an update has been released. It's going on 12+ years now since last update. Can we get a bone thrown to us even if it's just a few bug fixes, it would be cool to see this software come alive again.

Thank you.

Glad it helped! It always feels good to be right.

Hello, The country of origin is Taiwan