8

The region mask appears to be changed to 0x00000000 when using various ripping software which can decrypt (i.e. remove the DRM) the discs.

mpv reports:

libdvdnav: DVD disk reports itself with Region mask 0x00000000. Regions: 01 02 03 04 05 06 07 08

VLC in turn:

dvdnav demux: DVD disk reports itself with Region mask 0x00000000. Regions: 01 02 03 04 05 06 07 08

Does this mean that the region restrictions have simply been patched out? Why the string is 0x00000000 and not just 0 ('global'), or all flags from 1 to 8?

user198350
  • 3,769
  • 15
  • 50
  • 89
  • 10
    `0x00000000` and `0` are the same number. – MechMK1 Mar 30 '22 at 14:06
  • @MechMK1 While this is correct in isolation, it's not in the case of the message shown. The `0x00000000` isn't simply "the region mask as a number", instead, the eight bit mask is at the position marked `..` in `0x00..0000` in that message. – mossymountain Apr 03 '22 at 18:25

4 Answers4

22

The region code has been set to all regions

Source: It's been a few years since I had a full ~9" stack of DVD specs (physical to logical) sitting on my desk, but I used to work in anti-copy protection of DVDs. Much of this info is also available at https://en.wikipedia.org/wiki/DVD_region_code

The field-size issue

I'm 99% sure that the field is 16-bit, and as @harrymc says, the apparent 32-bit number is a red herring. In any case, only the bottom 8 bits were used. This was common in the DVD spec, where lots of fields had reserved bits for potential future expansion.

0x00 signifies playable in all regions

The bit-field is inverted – a '1' in the bit means the DVD is not permitted to play in that region. So a region of '0x01' means it may not play in region 1 but may play elsewhere. A region 1 disk is coded 0xFE.

Thus a region of '0x00' means it is playable in all regions.

Most rippers alter the region to 0 when ripping, as historically one of the main reasons for ripping (or at least the main quasi-legal reasons!) was to defeat region restrictions, and there's no downside for them in doing so.

Heinzi
  • 3,697
  • 9
  • 35
  • 50
Dan W
  • 321
  • 1
  • 3
9

The values of 0x00000000 and 0 are identical. The only difference is in the program that is writing out the code.

The code 0x00000000 is printed using the hex format, while 0 would have been the value if written out as decimal.

This is just the way that libdvdnav is programmed, using a print that specifies the hex format.

For programming information see the fprintf function.

harrymc
  • 455,459
  • 31
  • 526
  • 924
  • 2
    I don't really agree with this. printf 0 in hex would give 0x0. Your example is zero padded to 32-bit, which is of course numerically equivalent, but that has nothing to do with it being hex since you could also have zero padded (decimal) 0 to 000000000, which would also be 0. – Opifex Mar 30 '22 at 08:17
  • @Opifex: fprintf is not that limited. – harrymc Mar 30 '22 at 08:21
  • 1
    What do you mean it's not that limited? I didn't mention any limitation? Following your own link to the C++ reference it also shows a description of zero-padding. (2nd table, last row) – Opifex Mar 30 '22 at 08:30
  • @Opifex printf is not that limited in that it is capable of printing numbers in hexadezimal format with leading zeroes. `printf("%010x", 0)` produces `0x00000000` and harrymc simply said that libdvdnav happens to use this format string. – orithena Mar 30 '22 at 08:44
  • 1
    @orithena I'm confused. Isn't that exactly what I pointed out? printf can print a number in any format (dec, hex, oct) with or without leading zeroes. The leading zeroes are not part of what defines the format. – Opifex Mar 30 '22 at 09:14
  • @Opifex Yes, and it also is what harrymc pointed out. I don't see why you commented "has nothing to do with hex" when harrymc simply wrote "is printed using the hex format" -- which is correct, even without a mention of leading zeroes. – orithena Mar 30 '22 at 09:56
  • 2
    @orithena The reason I pointed it out is because right now it is implied that 0 converted to hex is 0x00000000. In other words: that hex requires those zero-pads. Which is not the case of course. The hex conversion has nothing to do with it. – Opifex Mar 30 '22 at 10:22
  • @Opifex As far as I can see, it is only implied that _one_ way of converting 0 to hex yields `0x00000000`. I don't see any implication that it would be _the_ way (although we commonly do print hex numbers with leading zeroes). Which shaped my comments: It did not occur to me that _this_ would be the point of your comment (and, I presume, harrymc thought likewise), so I tried to resolve it by looking at that misunderstanding from another angle. – orithena Mar 30 '22 at 13:00
  • 1
    @orithena That is indeed exactly what I meant: converting 0 to hex does not yield 0x00000000 but 0x0. Of course it is numerically equivalent to 0000000 and 0x0000000, but it would also be equivalent to 132487*0. You say it's commonly printed with 4 bytes, but that is only because you are used to working in a 32-bit environment. I come from an electronics background where this is a lot less common. – Opifex Mar 30 '22 at 15:09
  • While the answer in isolation is correct, it's not in the case of the message shown (the `0x00000000` isn't simply "the region mask" as a number; the eight bit mask is at the `..` in the value `0x00..0000` in the message the question is about. – mossymountain Apr 03 '22 at 18:22
7

The region code is handled as a 'bit mask' because any given DVD can be coded for multiple regions. The region code of 0 (global) is equivalent to no bits set in the mask. Assuming that the bits are numbered from right to left (the usual sort of thing that's done in computers), the region codes would be

  87654321
0x00000000

so that a disc that was coded for US/Canada (region 1) and Europe/Middle East (region 2) would have the region mask

  87654321
0x00000011

and one that was coded for US/Canada (region 1), Latin America/Australia/Oceania (region 4), and Southeast Asia (region 3) would have the region mask

  87654321
0x00001101

eta: I actually got the bits 'flipped' in the explanation above; per https://www.askingbox.com/info/the-dvd-region-coding-and-its-technical-implementation, a 1 in a bit position locks out that region, and a 0 enables playback. So, the first example should be 0x11111100 and the second 0x11110010. This is still a single byte in binary, however, not the full 32-bit word that the notation implies.

Jeff Zeitlin
  • 4,416
  • 2
  • 16
  • 30
  • 17
    This would make sense if the prefix were 0b (binary), but it's not; it's 0x (hexadecimal). 0x00000000 is a 32-bit number... – kwc Mar 30 '22 at 01:59
  • Australia/Oceania is put in the same category as Latin America, but not Southeast Asia? Europe / Middle East makes sense, because they're so close together, but... Is it just because Australia and New Zealand are considered Western countries? – Panzercrisis Mar 30 '22 at 02:10
  • @kwc - yes, it's a 32-bit number, but I'm not the one that decided how it gets encoded/decoded... – Jeff Zeitlin Mar 30 '22 at 11:04
  • 1
    @Panzercrisis - Ask whatever organization decided on the regions about that; I'm just using the information in Wikipedia. – Jeff Zeitlin Mar 30 '22 at 11:05
  • @JeffZeitlin: I'm pretty sure that's *not* how it's encoded. Looking for examples of region masks, I see [things](https://unix.stackexchange.com/questions/607808/dvd-reader-able-to-read-a-zone-1-dvd-only-internally) like "DVD disk reports itself with Region mask 0x00fe0000. Regions: 1", which is nothing like what your answer would suggest. – user2357112 Mar 30 '22 at 15:45
  • @user2357112supportsMonica - You're correct; I got the bits flipped - see https://www.askingbox.com/info/the-dvd-region-coding-and-its-technical-implementation. A 1-bit says that the region is locked out; a 0-bit says it's playable. – Jeff Zeitlin Mar 30 '22 at 17:38
  • 2
    @JeffZeitlin: But `0x00fe0000` is still completely different from what your explanation suggests. – user2357112 Mar 30 '22 at 18:01
  • @user2357112supportsMonica - there's clearly some byte/word swapping involved in your particular finding. – Jeff Zeitlin Mar 30 '22 at 18:02
  • 11
    The current layout of this answer is weird. You state one thing and then *at the end* you say it's the other way around. If you want to keep the part you now believe is wrong, explain *at the beginning* why you're doing this. For now a newcomer sees your upvoted answer, reads it in a hope of learning something, and after they build a mental picture and maybe start to think "oh, this makes sense", you turn it all upside down. This is not how you spread knowledge. – Kamil Maciorowski Mar 30 '22 at 18:22
  • 2
    This is not how bits are numbered usually, they are numbered consecutively, and what this answer numbers are nibbles, not bits. This answer is very wrong. – Remember Monica Mar 31 '22 at 07:20
  • This *is* how it is handled, and the bit-mask description is basically correct, but the OP has most definitely mixed up the numeric representation. The described method above uses binary for the illustration (common as they are thought of as switches in this usage), but regardless of binary decimal or hex, the bit mask works essentially this way. IIRC, If `foo_flag=32` one would set the flag "on" with `bitmask_var OR foo_flag`; test it with `(bitmask_var AND foo_flag) = true`; unset it with `bitmask_var AND NOT foo_flag` see ( https://stackoverflow.com/questions/18591924/how-to-use-bitmask ) – Yorik Mar 31 '22 at 16:36
5

Its region mask is zero, meaning it's playable everywhere. The message is the same when playing any non-region-restricted DVD (it does not have to be ripped).

In the message, the 8-bit region mask is sort of hidden inside the 32-bit long value*.
Here's what running mpv dvd:// said about four different commercial DVDs I have:

libdvdnav: DVD disk reports itself with Region mask 0x00fe0000. Regions: 01
libdvdnav: DVD disk reports itself with Region mask 0x00fd0000. Regions: 02
libdvdnav: DVD disk reports itself with Region mask 0x00e50000. Regions: 02 04 05
libdvdnav: DVD disk reports itself with Region mask 0x00000000. Regions: 01 02 03 04 05 06 07 08

In the first example, the region mask 0xfe (0b11111110) means regions 8 to 2 are masked:
It's only playable in region 1. (Only the rightmost bit is zero.)
The inverse (one's complement) of that mask, 0x01 (0b00000001), would mean the opposite: Region 1 is masked, it's only playable in the other regions.

*: It could be some sort of debug thing or an oversight why it's displayed like this. Although the logic doesn't change, it only reveals itself when there's a non-zero mask (the first three examples).

mossymountain
  • 111
  • 1
  • 4