2 Noobish Questions - Answered

Discussion in 'AnyDVD HD (Blu-ray issues)' started by EBITAD, Aug 4, 2019.

  1. EBITAD

    EBITAD Member

    Hello, although I have been using Any DVD for years, I find myself with two questions:

    1. Sometimes the following message occurs while trying to burn an ISO file of a previously ripped Blu-ray to a 50GB BD-R : "The source needs to be preprocessed into a temporary directory and then an ISO file will be generated" This appears to be random. This increases the time to burn from 2-3 hours to a day. Is there something I could do to prevent this?
    2. Can My LG WH16NS40 BD-RE drive rip a B Region Code Blu-ray to an ISO file so that it may end up as an A Region Code or no Region Code? I have my Any DVD set to remove Region Codes but I don't know if my LG drive may reject a B Region Code Disc.
    Thank you for any answers to the above.
     
  2. theosch

    theosch Well-Known Member


    The only thing about DVD- and BD region code both have in common, is that BD-region-codes are stored on the BD-DISCS, as it is with DVD discs.

    Blu-ray region coding checking is a software issue.

    Blu-ray drives PC-drives (external/internal) for example do not store Blu-ray region codes in their drive's firmware. Afaik on BD-standalone players the checking code is also in their playback software/OS system.
    Like DVD drives, BD-drives only store DVD-region codes.

    But differing drom DVD, the checking-code for BD-region-code is in some playback software (licensed) like PowerDVD which check and/or Windows registry (not exactly sure where), but not in the hardware's firmware! I'm not 100 sure, or the BD-checking code is also on the BD-disc, but not in the BD-drive's firmware. If this BD-checking-region-code is also on the BD-disc, it just get's active when certain Playback software like PowerDVD running this Java-code.
    But there are many free Playback-software which don't run this code.

    Only DVD-region codes are within the DVD's and BD's-drives firmware.
    --
    So MPlayer and VLC (and Kodi etc. afaik) for example don't check BD-region codes, even if you copied BD falsely with wrong disc-region code setting. It still plays fine with those, but afaik the region-code on the copy can be corrupted, not correctly removed, but Mplayer and VLC don't matter, and (maybe some region-free standalone players), but standalone players which are not region free and some licensed Playback software , which check for BD-region codes, could/will make problems with playback with corruped/incorrectly removed region-code copies.
    So afaik Mplayer, VLC, Kodi for can also playback region-coded discs, as long as all other hindering protections (like AACS, etc), (and with AACS still intact and you know AACS key)
    Also they don't check for Cinavia Audio water marking code being on some BD sics, which signals PowerDVD, and most newer BD-standalone players to blocks playpack after few minutes, but MPlayer, VLC, and Kodi don't take care of this blocking code :)

    So when attempting to backup a region-coded BD-disc, it is mandatory to declare the correct region of the BD-disc to AnyDVD, so PowerDVD software e.g. won't make issues.
    If removing the region-code, declaring the correct BD-disc region code to AnyDVD in the first place is very important, because afaik it's not possible, or at best rather only in rare cases to try to remove BD-region code correctly afterwards from old copy, where it was tried before with wrong region-code setting.

    When BD-disc is A+B or A+C or B+C, you can choose any appropriate region (which is inluded) in one of a pair.
    So if disc is A+B e.g. you can copy with AnyDVD set to region A or set to region B.
     
    Last edited: Aug 5, 2019
    EBITAD likes this.
  3. Ch3vr0n

    Ch3vr0n Translator NL & Mod

    AnyDVD can only remove the region and make it playable in all regions due to that. Neither AnyDVD nor CloneBD (or the combination) can recode the disc to a different region. It's either the region it came with, or all regions
     
    EBITAD and theosch like this.
  4. EBITAD

    EBITAD Member

    Thanks so much, the option to change from a "B" to all regions will work for me. Any thoughts on the need to preprocess?
     
  5. Ch3vr0n

    Ch3vr0n Translator NL & Mod

    What do you mean preprocess? You enable the region removal setting, your specify the region the DISC is FROM (NOT the region you want it to be), and rip. All done

    Sent from my Pixel 3 XL using Tapatalk
     
    theosch likes this.
  6. Jon G. Dunkelberry

    Jon G. Dunkelberry Active Member

    By "preprocess" he's asking about his first question in the original post. His second question (about regions) was answered.
     
  7. theosch

    theosch Well-Known Member

    Oh sry, you're right. :)
    Does burning work on any 2nd or e.g. 3rd attempt on the same ISO, where burning had failed/took unusually long ?
    Did you try with different type of blanc media? Did you change to another brand of blanc media recently?

    You said it occures randomly? Since when did this randomness of "The source needs to be preprocessed into a temporary directory and then an ISO file will be generated" happen?
    Did this randomness of burning delay happen also from ISOs made with ealier AnyDVD versions?

    Which burning-capable software did you take (ImgBurn, Nero, CloneBD, ...) ? Did this ever happen e.g. with ImgBurn or any other bruning software? Did you change burning software? Did you change burning/ripping drive before it started to occur?
    Did you change/update WH16NS40 firmware?

    After waiting a day, does the burning process end successfully? Does it start at all? or hangs with ISO needed to be preprocessed?
    Is the filesystem on HDD/SSD tested OK (=cmd as admin => chkdisk -f Your-driveletter: ) where ISO stored? Damaged sectors on SSD/HDD where some ISO is stored? (check SMART information data of SSD/HDD)

    Does your optical drive also have burning delays with crating e.g. data non-movie BD-R DL/RE DL (50 Gbyte)?
    Is the random burning issue only with burning BD-R DL /BD-RE DL(50 Gbyte) or also happening with BD-R SL / BD-RE SL (25 GBytes) ?
    Is your unit becoming defective, or its lens dirty? (afaik s.o. still warned not to clean lens, e.g. not even with a cleaning disc set, as even that got even small-scratches into the lens, which reflect/scatters the laser light which hinders drive to focuse correctly)

    Did those ISOs have read-errors when ripping (due to damaged BD-Disc)? (so bit missing data)
    Can you mount that ISO without issues with Virtual Clone Drive or Alcohol or Daemon Tools?

    If yes, is the mounted ISO playable?

    Did the blanc media taken for burning, where delay occured, have scratches in the first place when attempting to start to burn?
    Did you use an SATA-USB-adapter (e.g. using drive externally)?

    (Afaik when I burned e.g. a DVD disc which big scratches I had a delay with disc-sector error warnings, but I can't remember if that was during the writing-process or during verifying written disc. (So I don't know for sure if during write process, if there is a small verification process at same time, or just after verification)

    Sry, it's many questions, just an idea/suggestion to orientate, maybe a circumstance has changed and s.th. more to report :)
    --
    I'd rather think it's not the drive, because if it's happening only randomly there are also successful burns.
    If further attempts with burning image don't work, also with any other brand of blanc und good quality media like e.g. Verbatim not too old, not stored in sunlight, and really clean, no dust, no scratches, fat on it )doesn't work, too, also not with other units, but with other images there's no delay, then I'd say maybe s.th. with image or maybe a bug with burning software, that it doesn't like some images.
     
    Last edited: Aug 5, 2019
  8. Pete

    Pete Forum Admin Staff Member

    Commercial dual layer discs sometimes require slightly more space than a BD-R blank can offer. Writeable blanks have slightly less capacity than the "nominally" same sized pressed discs.
     
    theosch likes this.
  9. EBITAD

    EBITAD Member

    This was very good process to orient me as you state above. I very much appreciate it. Maybe it is just the original disc was old and scratched and while it ripped fine it does not burn well.
     

    Attached Files:

  10. Ch3vr0n

    Ch3vr0n Translator NL & Mod

    The ripped content does not affect how well it gets burned to a disc. There's only 2 factors that do that, 1) The brand and type of blanks you use (in case of BD's, there's only 1 type called BD-R) but the brand very much does matter, and 2) the speed you're burning to disc.
     
    theosch likes this.
  11. theosch

    theosch Well-Known Member

    @EBITAD
    Could you check in CloneBD burning software, of the info of the ISO-image, how many sectors ([edit] and in Bytes) there are used on the image.
    Bytes to write = Used "Disc sectors" of the image * 2048 Bytes / Disc sector
    (One disc sector on ISO9660; ISO9660+UDF; UDF alone = 2048 Bytes)

    If you couldn't find the info in CloneBD, then take e.g. ImgBurn.

    Mount the ISO, which had the delays in burning, in Virtual drive,
    and then open ImgBurn.
    Then click on "Create Image from Disc".
    Unbenannt18.PNG

    In next dialog select the Virtual drive's letter with the mounted image.
    In the next dialog ImgBurn-window changing to, on the right side look what ImgBurn Media/drive-info dialog reports, and write down the disc sector count info, an in bytes, of the virtual-disc info (from the image). Or just post screenshot here of this ImgBurn-info.
    E.g. Image from Avatar, uses over 50,050,629,632 bytes Bytes of space, that's slightly more than 50GigaBytes, afaik near to maximum that fits on a BD-R DL. At least haven't had any issues burning that to e.g. a TDK BD-RE DL (rewritable).
    Unbenannt15.PNG
    Unbenannt16.PNG
    Unbenannt17.PNG

    Also please check how many sectors of free space the whole blanc-disc offers to write to, also write down the available free space in (Bytes).
    Put BD-R DL blanc disc into unit, but do NOT burn anything to it.
    Again open ImgBurn, just select "Burn Image to disc", (but do NOT select any image to burn in next dialog).
    In the next dialog ImgBurn-window changing to, on the right side look what ImgBurn Media/drive-info dialog reports, about the blanc disc and write down the (free) disc sector count info , and in Bytes, of the blanc disc BD-R DL disc.
    Or just post screenshot here of this ImgBurn-info of the blanc disc.

    Compare free space disc sector count, and in Bytes, of the BD-R DL blanc listed with the value of the used space of the virtualiced disc from the image.
    --
    If the image was a bit too big, probably the conversion to compress to smaller image takes so long
    (as video material is aready highly compressed, and recompressing to get a bit smaller size, out of it is quite effortful, and has afaik small quality loss, as it's decompressing video material, and needs to recompress), but might be sufficient to burn a reprocessed image to disc, (if that was the case)
    --
    If the image was too big. Maybe "reprocessing" yourself is faster.
    When you copy a BD-disc, or recopy from image with CloneBD to new image, I've just checked, CloneBD offers to not include all features of the BD-disc, e.g. to remove some trailers/adds, audio language etc., even when it's not transcoding, but also with the option "Create ISO/folder structure"
    1:1
    or with
    ->"s.th. similar hide/dismiss some content" (German "Inhalte ausblenden")
    You can select, what content to remove, eg. best to remove trailers/adds, and, if that still doesn't get image small enough, remove audio languages etc

    This will be probably faster for reprocessing, afaik there's no addional decompressing/recompressing/transcoding process.
    --
    @Ch3vr0n
    Yes. I'd assume he was burning with slowest speed his BD-R DL. About 2 h. hours that's the time it took to burn a 50GBytes sized image to BD-RE DL (at 2x speed).
    (Afaik on most BR-Rs/BD-REs 2x is slowest offered speed.)
    ---
     
    Last edited: Aug 14, 2019 at 1:00 AM
    whatever_gong82 likes this.
  12. EBITAD

    EBITAD Member

    Theosch,

    Thanks so much, I will endeavor to follow each step of the above after the current disc is burned. It has happened now 3 times in a row and happens if I attempt to rip to an ISO file or to burn an ISO movie file to a disc. It does not appear to be related to the media as the "preprocessing" occurs prior to the burning. See the attached screenshot. Once burning begins the typical 2 to 3 hours to burn occurs. IMGburn can rip the same file to ISO in less than an hour.
     

    Attached Files:

  13. theosch

    theosch Well-Known Member

    I don't know for sure if it was related to the image<->blanc media (e.g. its used size, but too small for the blanc media) with the burning delay, which Pete suggested can happen, that pressed BD-ROMs (e.g. with Dual layer) could offer more space, to do/manufacture more data on it) than a BD-R DL could (probably rewritable BD-RE DL too).

    It (might) be possible.
    We'll see for sure when you check the used space of the image, in e.g. bytes and sectors, see above steps from post before, and compare its size with the available free bytes and sectors of the blanc disc.

    And you said the delay with CloneBD was not only with burning, but also with ripping from disc to image with CloneBD, correct?
    If that was the case also, it might be that CloneBD detects that resulting ISO from the original disc would be be bigger than would fit on a BD-R DL, that it was also already doing a preprocessing when making the first step ripping from original media.
    --
    (EDIT) Update 14 August 02:14 CEST: When you select BD-XL or BD-R DL or BD-R (without L), there are different compression-bitrates offered, so CloneBD might do a reprocessing in the first place, already when ripping from original-BD-ROM-disc to image (even offered on ->"1:1" option - full content)

    So ImgBurn might ignore also a too-big-detected size of the original-BD-ROM for a BD-R DL, and just creates image (pretty sure that was the case). But maybe ImgBurn just bringing a yellow warning note thereto.

    (So when e.g. an Image made from original disc by e.g. ImgBurn, and attempting to burn that to a blanc media with CloneBD instead, and the image size doesn't fit on BD blanc, of course CloneBD would also do the preprocessing, causing the delay.)<==kind of problem in this step afaik you provided in 1st post.

    Please don't get me wrong. Afaik it could be maybe rather more or less "rare" situation, that a movie on a pressed BD-ROM would make use of all available space, so that that kind of situation would happen, that it wouldn't fit on a BD-R DL, so that CloneBD would attempt an automatic reprocessing.
    (We'll see for sure when you check the used space of the image, in e.g. bytes and sectors, see above steps, and compare its size with the available free bytes and sectors of the blanc disc.)
    ---
    Another test method than comparing the sizes of Image and Disc, if the source had too much size.
    Just take ImgBurn and rip an image from the BD-ROM source disc where ripping/burning-delay occured wirh CloneBD (image also made with ImgBurn, but not not tested to burn that image with ImgBurn yet)
    Just try to burn also, the image made from original-disc with ImgBurn, to a BD-R DL/BD-RE DL with ImgBurn to blanc media (so that not any preprocessing with CloneBD had happened). If ImgBurn goes through with burning without such complaint, then I'd assume it was CloneBD.
    (EDIT) Update 14 August 02:14 CEST: Or s.th. to do with a setting you did in CloneBD: e.g. chosen BD-XL disc "layout" setting in CloneBD (not sure).

    See also tipnote at the bottom, not to waste several BD-R DL. :)
    ---

    If you had this tested this ripping+burning behaviour-delay with many different source material, (un)-preprocessed), so with many different original BD-ROM movies (that even have lower size than needed) or with many (un)-preprocessed images made from different BD-ROM movies (that even have lower size than needed), then it could be a CloneBD issues, that it always wanted to preprocess an image when attempting to rip from it or burn it.

    Tip: I'm not 100% sure if the free space of of a BD-R(E) DL (rewritable) was identical to a BD-R DL (one-time-recordable), (for e.g. size comparison tests). If that was the case, doing test burns with a BD-R(E) DL might be wise, as you don't need to waste several BD-R DL. :)
     
    Last edited: Aug 14, 2019 at 1:22 PM
  14. EBITAD

    EBITAD Member

    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.
     
  15. Ch3vr0n

    Ch3vr0n Translator NL & Mod

    Disc manufacturing calculates in values of 1000 aka 1GigaByte : 1,000,000,000 bytes. software does that differently and calculates in GiBiBytes.Every piece is software boils down to 1's and 0's (binary) and calculates in values of 1024. That includes numbers.

    1 GiBiByte: 1,073,741,824 bytes approx

    50,000,000,000 / 1020^3 boils down to actual useable space of about 46,6GB. Anything above that is too large and needs to be shrunk down.

    The same applies to BD25, they don't hold 25gb but only around 23,5.

    Sent from my Pixel 3 XL using Tapatalk
     
    whatever_gong82 and theosch like this.
  16. theosch

    theosch Well-Known Member

    [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)

    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)
    Unbenannt20.PNG
    (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 GiBytes (=GibiBytes) =a 2er-potenz prefix (binary prefix) (1 GiByte = 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/ (1073741824 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 Gibi(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.)
     
    Last edited: Aug 14, 2019 at 1:06 PM
    whatever_gong82 likes this.