Darkfalz Posted February 4, 2007 Posted February 4, 2007 I read many places files > 2GB are not possible on ISO9660, but doesn't seem a problem for ImgBurn. Then I read this on Wikipedia: The 2 GB file size limitNormally, a file on a ISO formatted disc cannot be larger than 2^31-1 in size, as the file's size is stored in a signed 32 bit value, for which 2^31-1 is the maximum. It is, however, possible to circumvent this limitation by using the multi-extent (fragmentation) feature of ISO 9660. With this, files larger than 2GB can be split up into multiple extents, each not exceeding the 2 GB limit. Empirical tests with a 4.2 GB fragmented file on a DVD media have shown that Microsoft Windows XP supports this, while Mac OS X (as of 10.4.8) does not handle this case properly. In the case of Mac OS X the reason is that its driver apparently does not support file fragmentation at all (i.e. it only supports ISO 9660 Level 2 but not Level 3). So, is this what ImgBurn does? I'll probably only ever be reading the files in Windows (maybe a standalone DivX player if I ever find a decent one) so is it okay or should I maybe switch to UDF? UDF filesystem overhead is huge, which is why I don't use it at the moment, plus Joliet is better supported ATM for devices such as DivX players.
LIGHTNING UK! Posted February 4, 2007 Posted February 4, 2007 I looked all through the ISO9660 specs and didn't see 1 mention of it being a 'signed' int. I tired a disc where I took it to be an unsigned int and every windows OS reported the size correctly - thats was enough for me to leave it implemented as such.
Darkfalz Posted February 5, 2007 Author Posted February 5, 2007 Sounds like you are breaking spec, whether it works or not :}
lfcrule1972 Posted February 5, 2007 Posted February 5, 2007 I looked all through the ISO9660 specs and didn't see 1 mention of it being a 'signed' int.I tired a disc where I took it to be an unsigned int and every windows OS reported the size correctly - thats was enough for me to leave it implemented as such. Maybe the ISO9660 specs are a better guide than those on wikipedia ?
LIGHTNING UK! Posted February 5, 2007 Posted February 5, 2007 Yeah, again, the ecma-119 pdf document (ISO9660) only mentions 'signed' / 'unsigned' for 8 bit numerical values. The file size field is a 32 bit numerical value and nothing makes me believe it's anything but an unsigned value. 9.1.4 Data Length (BP 11 to 18)This field shall specify as a 32-bit number the data length of the File Section. This field shall be recorded according to 7.3.3. 7.3 32-bit numerical valuesA numerical value represented in binary notation by a 32-bit number shall be recorded in a field of a descriptor in one of the following three formats. The applicable format is specified in the description of the descriptor fields. 7.3.1 Least significant byte first A numerical value represented by the hexadecimal representation (st uv wx yz) shall be recorded in a four-byte field as (yz wx uv st). NOTE 12 For example, the decimal number 305419896 has (12 34 56 78) as its hexadecimal representation and is recorded as (78 56 34 12). 7.3.2 Most significant byte first A numerical value represented by the hexadecimal representation (st uv wx yz) shall be recorded in a four-byte field as (st uv wx yz). NOTE 13 For example, the decimal number 305419896 has (12 34 56 78) as its hexadecimal representation and is recorded as (12 34 56 78). 7.3.3 Both-byte orders A numerical value represented by the hexadecimal representation (st uv wx yz) shall be recorded in an eight-byte field as (yz wx uv st st uv wx yz). NOTE 14 For example, the decimal number 305419896 has (12 34 56 78) as its hexadecimal representation and is recorded as (78 56 34 12 12 34 56 78). Notice there's no mention of signed / unsigned and yet... 7.1 8-bit numerical valuesA numerical value represented in binary notation by an 8-bit number shall be recorded in a field of a descriptor in one of the following two formats. The applicable format is specified in the description of the descriptor fields. 7.1.1 8-bit unsigned numerical vaiues An unsigned numerical value shall be represented in binary notation by an 8-bit number recorded in a one-byte field. 7.1.2 8-bit signed numerical values A signed numerical value shall be represented in binary notation by an 8-bit two's complement number recorded in a one-byte field. ... for 8 bit numerical values, the document does mention signed / unsigned stuff.
blutach Posted February 5, 2007 Posted February 5, 2007 We went thru this before IIRC. It's unsigned - why rely on wiki? I can write in wiki the sun rises in the west - doesn't make it true. Regards
lfcrule1972 Posted February 5, 2007 Posted February 5, 2007 I always verify independently anything I take from wiki for that reason..... Most stuff is ok but sometimes you can just see the text is wrong
Recommended Posts