[Edit]
Ch3vr0n got it nailed down and explained short very well as always, and much better
sry for my long text of blabla below (I was busy writing post, while he was answering)
Gee I feel stupid. The suggestions above caused me to check the capacity of the 50 GB discs I am using and only 46.6 GB is available. After checking a dozen titles of various size, if a file is much larger than 46.6 preprocessing is required. Stay at or below no preprocessing is required. It is a simple as that.
Thanks everyone, great support. Really appreciate it.
Yes it might be. (Not that you were stupid,
no I mean, that there might still be with the size issue of too few space of the blanc disc with some ISO-images)
(see below why to compare in Bytes and not as (see confusion problem with those prefixes (see below) and not in "GB"
If you use Bytes only,
without any prefix, (see ImgBurn window), you can avoid that issuee why further below)
Just done some small conversion calculation between two different size measuring units, it strongly indicates there might have been a confusion
Attention: There is also
danger of confusion with those size-prefixes.
Sometimes those programs give beside the values of bytes also as "GB".
E.g. Windows-fike-explorer does that.
You can see that, because e.g. if Win-Explorer shows e.g. 30 GB (example) of free space, next to it there is also the byte-value, and it clearly doesn't show 30,000,000,000 bytes, (it shows a bit more bytes than 30,000,000,000 Bytes)) so GB must be a binary prefix here instead (see example below)
You can check yourself in disk-property-window of Win-Explorer of your C-Partition, you will see (right-klick on drive C: ->drop-down menu ->properties)
(Another example below)
(size is circa 50,000,000 Bytes more (50 MegaBytes more) than 50 GigaBytes (about 0.05 GigaBytes more), but it still rounded 46.6 GiBytes after conversion into meant binary prefix GB=GibiBytes here):
So for Windows-the explorer they don't mean with "GB" GigaBytes =a decimal prefix (1 GB=1000*1000*1000 Bytes=1000^3 Bytes),
they mean with GB actually G
iBytes (=G
ibiBytes) =a 2er-potenz prefix (binary prefix) (1 G
iByte = 1 * 1024*1024*1024 Bytes = 1024^3 Bytes)
Same most probably with CloneBD seen from this case.
50 GigaBytes = 50 *1000 *1000 *1000 Bytes = 50,000,000,000 Bytes
So that 46.6 GiBytes available could be meant as 46.6 GibiBytes (GibiBytes) instead and that's more than 46.6
GigaBytes.
=>50,000,000,000 Bytes / (1024*1024*1024 *Bytes/GibiByte)
=50,000,000,000 Bytes * 1 GibiByte / (1024^3 Bytes)
=50,000,000,000 Bytes * 1 GibiByte/ (1,073,741,824 Bytes)
=46.56612873077392578125... GiByte(s) (GiBytes = GibiBytes)
≈46.6 GibiBytes
On a BD-R DL it fits (about) 46.56612873077392578125... GiBytes (GibiBytes)
46.56612873077392578125... GibiBytes
=46.56612873077392578125... GibiByte(s) *1024^3 Bytes / (1 GibiByte)
=50,000,000,000 Bytes
(≈46.6 GiBytes)
=>46.56612873077392578125... GibiBytes =50 GigaBytes
50,000,000,000 Bytes / (1000^3 Bytes/GigaByte)
=50,000,000,000 Bytes * GigaByte / (1000^3 Bytes)
=50,000,000,000 Bytes * GigaByte / (1,000,000,000 Bytes)
=50 GigaByte(s)
A BD-R DL in any case can fit about (at least) 50 GigaBytes (a
little bit more), that's for sure.
46,6 GigaBytes on a BD-R DL blanc disc of free space cannot be correct, they definitely can store at least 50 Gigabytes (a very few little bit more) (!)
The slightly difference of free space compared to a pressed BD-ROM it's just in a region of a few hundred MegaBytes if at all. Afaik the difference is up to a few MegaByte at max, perhaps only a diffence of few hundred KiloBytes, But's it's really not 3.4 GigaBytes in difference.
That ≈46.6 "GB" , it's meant as binary prefix (46.6 GibiByte) (!)
https://en.wikipedia.org/wiki/Bit
"Multiples of bits"
<==(see table
"Multiples of bits")
<==table uses bits as unit
<==8 Bit = 1 Byte
<==1 Byte = 8 Bit
But same shemata still applies here
1 GigaBit = 1000,000,000 Bit
1 MegaBit = 1000,000 Bit
(often used this, see internet connection speed from internet providers, and for networking card/onboard LAN-card speed)
(rather rarely seen this binary in practical case in normal life except maybe programmers (I Can't write program code or anything), what is shown right column in the wikipedia-table):
1 GibiBit = 1024^9 Bit = 2(^10)^9 Bit =2^(10*9) Bit = 2^90 Bit
MebiBit =1024^6 Bit = 2(^10)^6 Bit =2^(10*6) Bit = 2^60 Bit
KibiBit = 1024^3 Bit = 2(^10)^3 Bit =2^(10*3) Bit = 2^30 Bit
[EDIT]
1 G
ibi(Bit) convert to
Gibi(Byte):
(1 GibiBit =1 Gibi*Bit
1 Gibi*Bit=1000,000,000 * 1 Bit)
<==EDIT WRONG SRY
1GibiBit = 1024*1024*1024 *Bit <==CORRECT
=>1 Gibi*Bit /[8 * Bit/(1 Byte)]
= (1/8) * Gibi *Byte * Bit/Bit
=(1/8) Gibi*Byte
=(1/8) GibiByte
=0.125 GibiByte <==CONFUSING PART STILL CORRECT (see example few lines further below)
=125 MebiByte (CONFUSING PART, THAT THIS IS WRONG <=this line WRONG)
=128 MebiByte (CORRECT)
=>but still correct : 1 GibiBit = 1/8 GibiByte
==> Did just do a mistake later after that above (but above is correct), (below edited)
So this is still correct : 1/8 GibiByte =0.125 GibiByte
GibiBit to GibiByte convert:
1 GibiBit = 1/8 GibiByte =0.125 GibiByte
BUT WRONG===>1/8 GibiByte =>0.125*
1000 MebiByte/GibiByte =
125 MebiByte"
<==
WRONG
CORRECT==>1 GibiBit = 1/8 GibiByte = 0.125
GibiByte
= 0.125 GibiByte*
1024 MebiByte/GibiByte =
128 MebiByte <==
CORRECT
So it can be really confusing using mixing together with decimal places and/or fraction numbers, and/or especially when convert Bit-unit to Byte-unit by a 2e-potenz devider "8",
-
(On internet they choose decimal-prefixes, for the consumers, to more easy to understand)
(but using decimal-prefixes "K" "M" or "G", together with unit "Bit" instead of Bytes)
E.g. on a 1 MegaBit/s speed connection you get (Brutto - theoretical) in Bytes:
1
MegaBit /s = 1/8
MegaByte/s = 0.125
MegaByte/s
= 0.125 Megabyte/s *1000KiloByte/MegaByte =125
KiloByte/s (Brutto)
(Netto effective only about 120 KiloBytes/s with (Brutto) 1
MegaBit/s, so bit fewer effectively (
decimal (prefix used only in this example)
But the difference is still low, even if you used MebiBit instead, =128 KibiByte/s then instead, and that's not not so much difference to 120 KiloBytes/s (even with those different units on those still lower not so much differing factors here etc.)
---
Please don't get me wrong, it still might be that the BD-R DL doesn't have enough free space for your movie image.
If the value of used space in Bytes on the image is higher than on the blanc media (also in Bytes) available, then it's definitely not enough space available on the blanc media.
Just be carefull that if ImgBurn listed also as GB, they mean with GB prefix same as CloneBD (don't mix comparing by different measuring units)
So really shitty sometimes
Because normally "G" means Giga (*10^9 =>*1000,000,000), M = Mega (=> *10^6 =>*1,000,000); K = Kilo (=>*10^3 =>*1000)
Kilo ==>1 kg =1 KiloGramm =1000 Gramm
It's really distracting (when programmer use those decimal-prefixes for actually meaning binary prefixes)
That's why I suggested to look at the Byte value in the first place, of the e.g. mounted image in ImgBurn, and from the blanc disc (also in Bytes) , to avoid such confusion.
just don't mix with two different units when using anyone specific unit as a basic
Comparing used sector-count-value of image with the sector-count-value of free space of blanc media, as was proposed as well, is OK, too.
just don't mix with two different units when using anyone specific unit as a basic)
(See guided steps , provided with screenshots from ImgBurn from post #11 on same page here, few posts earlier.)