Property sheet question [RESOLVED]

[lezerogan2]

Another way to prevent NVIDIA grabbing keys (only if GeForce Experience is installed),
Is enter to GeForce Experience, enter settings, set "IN-GAME-OVERLAY" to OFF.

[MarkFilipak]

Ah! Thanks for that info. I did recently install GFE. Then I uninstalled it but it apparently left behind some cruft.

Now, if I can only figure out how to get virtualboxvm.exe away from NVIDIA. My virtual machine is running on the GPU without my permission or action and it's slowing down the VM -- yes, slowing it down. "NVIDIA Control Panel" > "Manage 3D settings" > "Program Settings" doesn't even list virtualboxvm.exe, yet "NVIDIA GPU Activity" > "Applications running on this GPU" shows virtualboxvm.exe. Optimus: The driver that uses the CUDA cores as coprocessors for use by the Intel integrated graphics, is awful. I do not recommend paying extra for a laptop with an NVIDIA GPU.

[MarkFilipak]

Hello All,
This is not a TC question ... well, it's sort of a TC question. You folks are the experts, so I hope you'll be kind enough to help.
I'm generating Blu-ray disc confirmation statistics [note 1]. For a randomly selected Blu-ray, I'm getting 4 differing disc sizes:

Code: Select all

                       31,776,263,171 -- 'DIR E:\ /S' == TC properties of E:
 15,518,624*2048      =31,782,141,952 -- 'CHKDSK E:' (used_sectors*2048)
                       31,782,731,776 -- Explorer properties of E:
(15,518,624+1913)*2048=31,786,059,776 -- 'CHKDSK E:' ((used_sectors+available_sectors)*2048)

Except for the obvious difference in 'CHKDSK', why am I getting 4 differing disc sizes?

[note 1] The idea here is to give users a way to compare differing versions of movies and thereby avoid wasting money on upgrades that are really just repackages, not real upgrades. In addition to bit rates and audio channels etc., in addition to the byte sizes of the important '.m2ts' files, part of that comparison is total Blu-ray disc bytes, but ... well, you see the problem, eh?

Regards,
Mark Filipak.

[Usher]

2MarkFilipak
You should always use /A switch when running DIR command to show and count all files and folders including hidden or system ones. Something like that:

dir E: /A /S

And in Total Commander you should change configuration to display hidden and system files.

[MarkFilipak]

2MarkFilipak
You should always use /A switch when running DIR command to show and count all files and folders including hidden or system ones. Something like that:

dir E: /A /S

I suppose that won't hurt, eh? though I doubt that UDF filesystems on DVDs and Blu-rays have either hidden or system files.

Do you have any insight into why 'CHKDSK' reports a differing (used_sectors*2048) and why Windows Exporer reports yet another differing byte count? That's 3 differing used byte counts: 1: 'DIR', 2: 'CHKDSK', and 3: Windows Explorer.

Okay, 'CHKDSK' is reporting sectors, not actual file sizes, but the numbers don't make sense.

Recapitulation:

32,222,087,342 - 'DIR G:\ /S'.
32,222,087,342 - Explorer, G:\, then select all, then 'Properties, Size'.
32,222,087,342 - Total Commander, G:\, then select all, then 'Properties'.
32,222,087,342 - Total Commander > Search *.* > Feed to listbox - (select files, only) - 'Properties, Size'.
-- They agree. But are they right? Or probably right? Or maybe right? Or unknown?

32,228,048,896 - Total Commander 'cm_SrcOpenDrives', then select G:, then 'Properties'.
-- This is the largest byte count, but it doesn't match any other byte count. Where/how is TC getting this number?

32,222,425,088 - Explorer, G:\, then select all, then 'Properties, Size on disk'.
32,222,425,088 - Total Commander > Search *.* > Feed to listbox - (select files, only) - 'Properties, Size on disk'.

32,227,459,072 - 'CHKDSK G:' - 2048 bytes in each allocation unit, 15736064 total allocation units on disk.
32,223,879,168 - 'CHKDSK G:' - 2048 bytes in each allocation unit, 15736064 - 1748 ('total allocation units on disk' minus 'allocation units available on disk').
-- What's significant about these numbers is not the ambiguous meaning of 'total allocation units on disk' (not significant because I've made calculations based on both meanings of 'total'). What's significant is that they are based on number of sectors, yet they don't match any other 'Sizes'.

What am I to believe? Do I need to get out a microscope and actually count the sectors?

This is not an academic issue. I would say that this should be an issue for TC, but I don't know what's correct, so I don't know from where the issue arises. What I do know is that I have almost 1500 DVD & Blu-ray discs that may need to be reassessed. The prospect of having to do that does not bring Joy.

And in Total Commander you should change configuration to display hidden and system files.

Of course.

Regards,
Mark.

[Dalai]

File sizes and how much space they actually allocate are two entirely different things. Make a test: Create a file with zero bytes in size. Is it actually zero bytes? Yes, of course. But does it allocate zero bytes on the file-system? Of course not. File-systems work in clusters of some size; for NTFS it's usually 4 KiB (but can be anything from 512 bytes to 64 KiB), for FAT32 it depends on how the volume was formatted and how large it is. Coming back to my example: the file would require a block of 4 KiB on an NTFS volume. Well, I'll skip the whole "no, it wouldn't because the file would actually be saved directly in the MFT" stuff, because that's a whole other can of worms. But you can repeat that test with a file of 4097 bytes and such file will allocate 8 KiB (assuming the NTFS volume uses 4 KiB clusters).

That's why TC shows two numbers in the Ctrl+L dialog, one for the actual size of the files and another one what they allocate on disk which takes the volume's cluster size into consideration (and a third one for the space required on the target). The properties dialog should also show two numbers: file size and space/size allocated on disk. The latter must be divisible by the cluster size.

BTW, for me it doesn't matter if the properties dialog called from TC or Explorer, they both show the same thing. And they're supposed to do that because it's the exact same dialog.

The file-system itself also allocates space, which is probably why chkdsk shows even higher numbers. The more files you have on a disk the more space the file-system allocates because the filenames and the other information about the files have to be saved somewhere. On optical media this is especially noticable. But it's also seen on freshly formatted volumes; maybe you've asked yourself why a freshly formatted volume already has some hundred megabytes used? That's the file-system reserving space for itself and the information about the files that are going to be saved in it.

[EDIT]
To moderators: I think the last couple posts about the file sizes should be moved to a new thread.
[/EDIT]

Regards
Dalai

[MarkFilipak]

File sizes and how much space they actually allocate are two entirely different things. Make a test: Create a file with zero bytes in size. Is it actually zero bytes? Yes, of course. But does it allocate zero bytes on the file-system? Of course not. File-systems work in clusters of some size; for NTFS it's usually 4 KiB (but can be anything from 512 bytes to 64 KiB), for FAT32 it depends on how the volume was formatted and how large it is. Coming back to my example: the file would require a block of 4 KiB on an NTFS volume. Well, I'll skip the whole "no, it wouldn't because the file would actually be saved directly in the MFT" stuff, because that's a whole other can of worms. But you can repeat that test with a file of 4097 bytes and such file will allocate 8 KiB (assuming the NTFS volume uses 4 KiB clusters).

That's why TC shows two numbers in the Ctrl+L dialog, one for the actual size of the files and another one what they allocate on disk which takes the volume's cluster size into consideration (and a third one for the space required on the target). The properties dialog should also show two numbers: file size and space/size allocated on disk. The latter must be divisible by the cluster size.

BTW, for me it doesn't matter if the properties dialog called from TC or Explorer, they both show the same thing. And they're supposed to do that because it's the exact same dialog.

Thank you for that confirmation. I know all about allocation and slack space, but I didn't know it is the same dialog (though I did suspect it).

The file-system itself also allocates space, which is probably why chkdsk shows even higher numbers. The more files you have on a disk the more space the file-system allocates because the filenames and the other information about the files have to be saved somewhere. On optical media this is especially noticable. ...

Can you give me a link to source material that confirms that DVDs and/or Blu-rays reserve disc space that's outside the UDF file system?

... But it's also seen on freshly formatted volumes; ...

I apologize that I haven't made clear what I'm addressing: I'm solely addressing UDF and my ability to include disc sizes into my disc reviews so that readers can easily confirm that my disc review applies to their disc. Of course, I'm including barcodes of course, but I've found 2 things, 1: movie studios occasionally release a different version (e.g. AVC codec instead of VP1 codec) with differering disc byte sizes but with the same barcode, and 2: movie studios often release the same discs with differing barcodes, and for those discs I include all the barcodes I've discovered, but the reader may contact me with another, new barcode.

... maybe you've asked yourself why a freshly formatted volume already has some hundred megabytes used? That's the file-system reserving space for itself and the information about the files that are going to be saved in it.

I believe that doesn't apply to UDF.

[EDIT]
To moderators: I think the last couple posts about the file sizes should be moved to a new thread.
[/EDIT]

Actually, this is the same topic.

[Dalai]

Can you give me a link to source material that confirms that DVDs and/or Blu-rays reserve disc space that's outside the UDF file system?

What do you mean outside the file-system? I didn't say anything like this. I just said that there's some overhead involved with file-systems, and the more files you save in a file-system the more overhead there is going to be. You can test that yourself: write a low number of large files to a disk (or disc since it's about optical media), then split these large files into chunks of 1 MiB and write those files to disc. The file-system overhead will be much larger in the latter case.

I apologize that I haven't made clear what I'm addressing: I'm solely addressing UDF and my ability to include disc sizes into my disc reviews so that readers can easily confirm that my disc review applies to their disc.

I see. I'm not sure if the size can be a reliable factor. But I don't know much about movies on DVDs and Blu-ray.

I believe that doesn't apply to UDF.

True. Still, even a UDF file-system grows the more files you save to it, as I already said above.

Actually, this is the same topic.

Well, the original question has been answered, hasn't it? We're not talking about this property sheet anymore, what it does and if it's the same across TC and Explorer, or any other file manager, for that matter.

Regards
Dalai

[solid]

Of course, I'm including barcodes of course, but I've found 2 things, 1: movie studios occasionally release a different version (e.g. AVC codec instead of VP1 codec) with differering disc byte sizes but with the same barcode, and 2: movie studios often release the same discs with differing barcodes, and for those discs I include all the barcodes I've discovered, but the reader may contact me with another, new barcode.

In that case wouldn't the checksum of the files be better indicator if the files are the same?

[MarkFilipak]

Of course, I'm including barcodes of course, but I've found 2 things, 1: movie studios occasionally release a different version (e.g. AVC codec instead of VP1 codec) with differering disc byte sizes but with the same barcode, and 2: movie studios often release the same discs with differing barcodes, and for those discs I include all the barcodes I've discovered, but the reader may contact me with another, new barcode.

In that case wouldn't the checksum of the files be better indicator if the files are the same?

That would seem a good idea, Solid, and I appreciate that you suggest a workaround but it will not work. 1: Only byte count is reliable because 'identical' videos often have small errors (that may or may not be corrected when decoded), and 2: Readers are not sophisticated and are not going to know how to make a checksum of any kind (no less of the right kind) but they will be able to run 'DIR' and thereby get a byte count.

It is possible that two different versions of a DVD or Blu-ray of the same named movie might have the same byte size, but that possibility is vanishingly small.

[MarkFilipak]

Update: I've managed to mount an opticel drive passthrough to my Linux virtual machine and have confirmed that Linux reads UDF and reports the same used-space as does Windows 'DIR'.

I'm satisfied and will solely use 'DIR' to read optical disc used bytes and I'll publish that in my movie reviews.

Thanks All. This issue is closed.