Burning DL media with PgcEdit [Archive] - Page 3

frank

15th June 2005, 11:25

PgcEdit 0.6.0 beta 4

The difference is greater.
There is only one VTS with menu in my example.

Burn Dual layer DVD: Select Layer Break
tot sec 3626104 max 4148992
Lbmin 1551616 max 2074496 opt LB 1813052
LB =L0 1838992 offs 51866 L0 is equal to my manual calculations!
burn 3677984 iso 3677970For calculations of iso length we must include the padding sectors in L0. Setting to 2 * L0 = 3677984 is useless.

IsoBuster 1.7:
Name LBA
VIDEO_TS.IFO 285
VIDEO_TS.VOB 291
VIDEO_TS.BUP 52177
VTS_01_0.IFO 52183
VTS_01_0.VOB 52230
VTS_01_1.VOB 52508
...
VTS_01_0.BUP 3677772The iso length is calculated by adding the size of VTS_01_0.BUP = 47
Isobuster iso = 3677819 to burn.
[edit]
difference = 3677970 - 367819 = 151 sectors
The difference is equal to the Footer constant in procedure burn.tcl. Something is mismatched, I will look.

jinjin_jp

15th June 2005, 14:51

I found the interesting things about the case that LayerBreakCell is first cell of VTSM.
There is the informaion in the site
*ttp://yaki2fan.hp.infoseek.co.jp/606/606_1.htm

In the case that PgcEdit recommend 'VTSM_2,Cell_1' ,select and process it,
Layer Break Point is between VTS_02_0.IFO and VTS_02_0.VOB.(Figure 3 and 4)

On the other hand, in the case of process by RecordNow automatically(because it can't sellect cell) about the same DVD-Video,
Layer Break Point is between VTS_01_4.VOB and VTS_01_0.BUP.(Figure 1 and 2)

----------------------------------------------------------------------------
Another information
The following is the excellence of PgcEdit compare with RecordNow.
PgcEdit can select LayerBreak LBA which is less and more than T(total LBA of original)/2.
But RecordNow seems to have the restriction that LayerBreak LBA must be more than T/2,
so can't precess and indicate 'Error' if appropriate cell LBA is only less than T/2.

mpucoder

15th June 2005, 15:20

According to what I've read about where the layerbreak must go, RecordNow is correct, L0 MUST be larger than L1.

jinjin_jp

15th June 2005, 15:50

According to what I've read about where the layerbreak must go, RecordNow is correct, L0 MUST be larger than L1.
Sorry,what I want say is like followings,

If total sectors is 10,000. and permitted maxmum is 12,000,
(Ideal layer Break is 5,000 from start sector.)
and cell end sector is 4,500 and 5,500.
(1)The case selecting cell end sector is 4,500 :
By padding 1,000 sectors in L0, L0=4,500+1,000=5,500,L1=5,500, so L0=>L1.
(2)The case selecting cell end sector is 5,500 :
L0=5,500,L1=4,500, so L0=>L1, too.
(where ignore must be 16 multiple)
Both case are no problem(L0=>L1).

PgcEdit permits be (1) or (2).
RecordNow permits only (2), so if cell end sector is only 4,500 ,it can't process.

Sorry if target outskirt.

blutach

15th June 2005, 15:54

I must admit that my original view was the same as that of mpucoder. Even though it is highly unlikely to ever come to this, it might be prudent to program the rule as L0 > L1, not >=

Now, onto my 2nd set of tests.

The enclosed spreadsheet (image) shows, in all instances, the PgcEdit reported sectors in L0 is universally 307 sectors (this time) higher than the sum of the sectors in L0. This, I must put down to the mkisofs overhead. The difference between frank and I could be that I am using the latest mkisofs as obtained from coujo's site. Are you, frank, possibly using the version that came with ITC 0.91.4 (mine is 0.91.5), as this would explain the major descrepency (I also understand that a sector is allocated per file, so that could be why it was 318 yesterday and 307 today)?

http://img166.echo.cx/img166/4163/zzzzzzzzzzzzzzzz3vl.th.png (http://img166.echo.cx/my.php?image=zzzzzzzzzzzzzzzz3vl.png)

Regards

blutach

15th June 2005, 16:01

@jinjin_jp

Yes, you are right, with the proviso that you pad 1,001 now.

Do not be afraid to link to websites you think we will find useful and interesting - you can post http:// and not *ttp:// OK?

Regards

jinjin_jp

15th June 2005, 16:05

About sectors it seems to be different between LBA of and each file and ISO.

For example (which I tested)

Pgc Edit shows,
Total number of sectors in compilation : 3,956,511

DVDDecrypter(FileMode) shows LBA of each file.
First file : VIDEO_TS.IFO 323-333
Last file : VTS_10_0.BUP 3,956,351-3,956,359
So Total number of sectors : (3,956,359-323+1=)3,956,037 ::: not same as PgcEdit

DVDDecrypter(ISOMode) shows
Sectors : 3,956,511 ::: same as PgcEdit
Size : 8,102,934,528 (/2,48=3,956,511) ::: same as PgcEdit
First Physical Sectors of Data Area : 196,608
Last Physical Sectors of Data Area : 4,153,118
So Total number of sectors : (4,153,118-196,608+1=)3,956,511::: same as PgcEdit

jinjin_jp

15th June 2005, 16:16

@jinjin_jp
Do not be afraid to link to websites you think we will find useful and interesting - you can post http:// and not *ttp:// OK?

Thanks. I will do so from next time.

(In Japanese site that I often visit, it seems to be considered the manner not to link direct,because sometimes causes troubles.)

blutach

15th June 2005, 16:20

Understood. And thank you. Bedtime for us, I fear :) 1:20 am here.

Good night :)

Regards

blutach

15th June 2005, 16:40

r0lZ

15th June 2005, 18:45

According to what I've read about where the layerbreak must go, RecordNow is correct, L0 MUST be larger than L1.Do you mean that L0 cannot be equal to L1?

mpucoder

15th June 2005, 18:55

I'm trying to find (wish I had bookmarked) the site with the capacities and densities of various DVD. But what it comes down to is L1 is recorded at a lower density (larger pits). Also L0 of a DL DVD has less capacity than a DVD-5. This is why a dual layer has less capacity than a dual sided.

r0lZ

15th June 2005, 19:53

But what it comes down to is L1 is recorded at a lower density (larger pits).This means that L0 must be largely greather than L1, right? Ennoying. For now, I assume that both layers are the same size. I hope you will find the site...

BTW, I just changed my code to ensure that L0 is at least one sector greather than L1. But it may be not enough.

mpucoder

15th June 2005, 19:55

OK, didn't find that site, but I did find this (http://www.t10.org/ftp/t10/document.05/05-130r0.pdf) which gives the sector addressing. According to it each layer has a maximum of 2176768 sectors - the same.

And Now I get to contradict myself, sort of. L0 should be shorter or the same as L1. BUT this is the physical sectors we are talking about, not the space that DVD-Video uses. Prior to any data there are 1 or 2 file systems, directories, pointer, lead in, etc. You've got to account for that (as in the above example there are 196608 sectors before VIDEO_TS.IFO) when choosing the layer break, which means L0 ends up shorter.

r0lZ

15th June 2005, 22:33

If I understand correctly, this means that the video sectors on L0 must be > video sectors on L1, but physical sectors on L0 must be < physical sectors on L1. Seems strange, as this doesn't leave many sectors to place the layer break.

So, may I safely assume that if L0 > L1, the burning program (DVD Decrypter) will pad L1 with blank sectors? It is what I have assumed so far, and, apparently, it works fine.

FilipeAmadeuO

15th June 2005, 23:52

So, may I safely assume that if L0 > L1, the burning program (DVD Decrypter) will pad L1 with blank sectors? It is what I have assumed so far, and, apparently, it works fine.

I think is exactly like this.

jinjin_jp

16th June 2005, 13:11

@r01Z
If possible, I'd like to request the feature in future.
The feature is to show the LBA of start and last of each file, like the function of DVDDecrypter(FileMode ,Properties), extending the function to show the sector of layer break cell.

I've been usually enjoyed to test various software in various way than backup itself.
Above DVDDecrypter's method need to the process of createing ISO file. Especially I spent much time when tested of comfirming LBA and correcting IFO variously.

r0lZ

16th June 2005, 22:31

Difficult to do, because this function requires a new interface, for a small advantage. And don't forget that most of the starting sectors will change after the selection of the layer break point. Currently, PgcEdit computes the starting sector of the files only before opening the GUI, to be able to display the valid cells. I don't want to add the code to calculate them again.
Anyway, to test, it is easy to read the starting sector of the VOB in DVD Decrypter or ISO Buster, and add the starting VOBU sector of the cell. The result should be equal to the LB sector number.

jinjin_jp

16th June 2005, 22:59

Thanks. I understood its difficulty isn't balanced for its effect.

r0lZ

17th June 2005, 08:12

My understanding is that DVD+R DL is 2,086,912 sectors, which is about 12,500 sectors more than a DVD-R DL (which is what is programmed in to PgcEdit Beta5). Am I incorrect?

And for DVD-5, a -R is supposed to be 4,488.0625Mb while a +R is supposed to be 4482.625Mb (and I can confirm that my Riteks +R03 have burned right up to this).
You mean 2,086,912 * 2 = 4,173,824 for a DL, right?

So, according to you:

A DVD-5+R is 2,295,104 sectors, 4,482.625 Mb (it is what I use in PgcEdit)
A DVD-5-R is 2,297,888 sectors, 4,488.0625 Mb

A DVD-9+R is 4,173,824 sectors, 8,152 Mb
A DVD-9-R is 4,148,992 sectors, 8,103.5 Mb (it is what I use in PgcEdit)

Seems strange: the DVD-5-R is larger than +R, but the DVD-9-R is shorter than -R ! Also, I was almost sure that the DL size hardcoded in PgcEdit was the size for a +R, since the -R format was not available until now.

Unless I can have a somewhat official confirmation of these sizes, I will not change the sizes hardcoded in PgcEdit. For now, the sizes used are the smallest ones. I think it's better, for safety. And anyway, the difference is too small to justify a more complex interface.

[EDIT:] I have found this site (http://www.osta.org/technology/dvdqa/dvdqa6.htm) which gives 2,294,922 sectors for DVD-5-R, which is less than the size of a +R ! But it says that the number of sectors available on a -R is not specified by the standard, at the difference of the +R format. Another good reason to use the +R size only.

r0lZ

17th June 2005, 11:46

I changed my mind. I have added two editable fields in the Burn Setup dialog to enter the number of sectors of a single-layer DVD and a DL DVD. After all, the best way to know for sure how many sectors are available is to look at the DVD Decrypter's infos in ISO mode.

BTW, someone know if it is possible to burn mini-DVD-VIDEOs (ie DVD-Video files on a CD-R) with DVD Decrypter?

blutach

17th June 2005, 12:39

It is strange there is not one uniform info on disk sizes! :)

Regards

r0lZ

17th June 2005, 15:36

From the site (http://www.osta.org/technology/dvdqa/dvdqa6.htm) cited above:
DVD+R, DVD+RW and DVD-RAM specify the number of sectors available for user information (1.46 GB DVD+R/+RW 714,544 sectors, 4.7 GB DVD+R/+RW 2,295,104 sectors, 1.46 GB DVD-RAM 714,480 sectors, 2.6 GB DVD-RAM 1,218,960 sectors, 4.7 GB DVD-RAM 2,295,072 sectors) so disc capacity can be calculated by multiplying the user data area size by the number of disc sectors. For example, a 4.7 GB DVD+R disc: 2,048 bytes/sector x 2,295,104 sectors = 4,700,372,992 bytes. This rounds to roughly 4.7 GB (decimal notation).

DVD-R and DVD-RW, on the other hand, do not stipulate the number of sectors that are dedicated to user information but simply that a minimum capacity must be available on the disc. In the case of DVD-R (version 1.0) this is 3.95 (12 cm) and 1.23 (8 cm) billion bytes and for DVD-R (Authoring), DVD-R (General) and DVD-RW 4.7 (12 cm) and 1.46 (8 cm) billion bytes. Consequently, real world capacity can vary slightly among discs from different media manufacturers although many have informally settled on 2,298,496 sectors (4,707,319,808 bytes) for a DVD-R (General) 4.7 GB disc.Yet another superiority of + over - !

frank

17th June 2005, 17:56

Right done rOlZ!
Originally posted by blutach:
My understanding is that DVD+R DL is 2,086,912 sectors, which is about 12,500 sectors more than a DVD-R DL[Edit]
The ECMA currently released the +R DL specs ECMA-364.
Data Zone is specified to 2 x 2086912 sectors max.
= 8 547 991 552 Bytes max.

-R specifies the minimum capacity and tolerances, not sectors.
Example: DVD-5-R Data Zone has a defined physical start address (030000H = 196608) but the end is defined by r9 = 57.5-58 mm and min 4.7 billion bytes. No number of data sectors.
DVD-5-R has (4.7 billion / 2048) mod 16 sectors min.
= 2 294 928 sectors min. = 4 700 012 544 Bytes min.

I think in the the real world the worst case capacity is sufficient. Remember my posting about read errors above.

And for the last bit backup fans: The capacity of a pressed DVD-ROM is greater than any of DVD+/-R DL. You must strip out something if you want to use the last percent of media.

blutach

18th June 2005, 01:37

I think, this is getting to the point where the user must pop his blank in DVD Decrypter in ISO mode and see what it says about capacity and enter it in PgcEdit.

The only thing that seems set is the DVD+R SL.

Regards

jinjin_jp

19th June 2005, 03:19

I could get some information about sectors of blank media, which was examined by requesting the companion who is always communicating by the BBS in Japan to cooperate.

Its method is actually examinin the sectors shown by various software when insert blank media.
Now there is not +R/SL, but it may be possible to obtain,because requesting another companion.
[Later could Add about +R/SL, like below.]

The information of the results is below :
*common condition of almost test
(1)software :
......(s-1)DVD Decrypter, shown as Free sectors on ISO-Read.
......(s-2)DVDIdentifier,shown as Blank Disc Capacity.
......(s-3)RecordNow(7.31), shown as Disc Infomation?(actually in Japanese)
......(s-4)Nero CD-DVD Speed, shown as Disc Info.
......(s-5)B'z GOLD(5.55), shown as Disc Infomation?(actually in Japanese)
(3)media :
......(m-1)as -R/DL : Mitsubishi Chemical, 4x
......(m-2)as +R/DL : Mitsubishi Chemical, 2.4x
......(m-3)as -R/SL : Hitachi Maxell, 4x
......(m-4)as +R/SL : Mitsubishi Chemical, 8x
(2)Drive
......(d-1)Pioneer DVR-109
......(d-2)Pioneer A08 (when +R/SL, and part of -R/SL)

*Results
(1)-R/DL
......(s-1)4,171,712sectors
......(s-2)4,171,712sectors
......(s-3)4,171,712sectors
......(s-4)4,171,713sectors (=8,543,668,224byte, shown by byte not sector)
......(s-5)not corresponding
(2)+R/DL
......(s-1)4,173,824sectors
......(s-2)4,173,824sectors
......(s-3)4,173,824sectors
......(s-4)4,173,825sectors (=8,547,993,600byte, shown by byte not sector)
......(s-5)4,173,824sectors
(3)-R/SL
......(s-1)2,298,496sectors
......(s-2)2,298,496sectors
......(s-3)2,298,496sectors
......(s-4)2,297,889sectors(=4,706,076,672byte, shown by byte not sector)
......(s-5)2,298,496sectors
(4)+R/SL
......(s-1)2,295,104sectors
......(s-2)2,295,104sectors
......(s-3)2,295,104sectors
......(s-4)2,295,105sectors(=4,700,375,040byte, shown by byte not sector)
......(s-5)Not tested

Consider and compare with
each sectors of PgcEdit's setting data
(1)-R/DL : 4,148,992sectors (approx)
(2)+R/DL : 4,173,824sectors
(3)-R/SL : 2,297,888sectors (approx)
(4)+R/SL : 2,295,104sectors

(a)shown value of each media is same except for by Nero.
(b)value of +R/DL is same as PgcEdit's (except for by Nero). [4,173,824sectors]
(c)value of -R/DL is bigger than PgcEdit's. [4,171,712>4,148,992sectors]
(d)value of -R/SL is bigger than PgcEdit's. [2,298,496>2,297,888sectors]
...(d.2)specifically the value by Nero is almost same, difference is only +1. [2,297,889sectors]
...(d.3)and more another information exists. the value by DVD Decrypter(s-1) is completely same as PgcEdit's[2,297,888sectors], when drive is pioneer A08 and HL-DT-ST GMA-4020B.　There seems to be difference depending on drive.
(e)value of +R/SL is same as PgcEdit's (except for by Nero). [2,295,104sectors]
...(e.2)specifically the value by Nero is almost same, difference is only +1. [2,295,105sectors]. Its differences(+1) of each media are same except for -R/SL.

I hope to become help a little.

jinjin_jp

19th June 2005, 04:38

@r01Z
Thanks for great program and its improvement.

I tried beta 6 and 7, and confirmed that multiangle-cell aren't shown in the selection list of LayerBreakCell.
And I'd like to know what about interleave-cells because I think interleave is similar to multiangle, and tested using Matrix which involves interleave-cells in PGC of the game(white rabbit appears).
The result was these cells have been shown in the list.

Is whether correct interleave-cells to be 'shown' or 'not shown' in the list?
(I think 'shown' means there is no problem if selected.)

blutach

19th June 2005, 09:16

@jinjin_jp

Thank you for this great info - I would not trust the Nero CD Speed. Maybe Nero Info Tool, but this seems wrong because it is not a multiple of 16.

Regards

r0lZ

19th June 2005, 10:53

@jinjin_jp: Thanks for the info.
I am sure that the numbers of sectors on DVD-R are NOT constant. They depends on the DVD manufacturer. So, I will keep the actual numbers of sectors hardcoded in PgcEdit. Seems safer to use the minimal number of sectors. And, thrust me, there are some DVD-R that are even smaller (notably Commodore).

About interleaved cells: I will try Matrix, and remove the interleaved cells from the list as well. Thanks!

jinjin_jp

19th June 2005, 11:40

About interleaved cells: I will try Matrix, and remove the interleaved cells from the list as well.
Thanks.
When trying, it is necessary to change the DVD sectors for the purpose of the test, if not, interleaved cells are in the appropriate range of LayerBreak.

I am sure that the numbers of sectors on DVD-R are NOT constant. They depends on the DVD manufacturer. So, I will keep the actual numbers of sectors hardcoded in PgcEdit. Seems safer to use the minimal number of sectors. And, thrust me, there are some DVD-R that are even smaller (notably Commodore).
I think better to be safer, too.

And I've got the information about -R/DL burning from companion who is always communicating by the BBS in Japan.
It is in here (http://yaki2fan.hp.infoseek.co.jp/-r_dl/-r_dl.html).
Where are tried in three ways of -R/DL burning, and examined SectorSize of ISO-total/L0/L1, StartSector of FirstFile, FileSize(sector) of L0/L1.
And more, LayerBreak is between original cell or newly in the one, description of LayerBreak is or not. The temporary stop during replaying.

Common of three ways seems to
(1)L0 is 2,092,896 sectors.
(2)There seems not to be blank cells between files, but StartSector of the file is adjusted.

Different feature in each way seems to
(1)Record now : Burned　considering that file size of L0 and L1 is almost same and LayerBreak is between cell and cell. And the description of LayerBreak is appropriately added in IFO.　（And if not removed LayerBreak from original, LayerBreakCell is same as original.)
(2)Nero : Burned from approximately the first sector ignoring cell. So worst, LayerBreak is in the halfway position of cell and the description of LayerBreak could not be added in IFO appropriately.
(3)rest : Burned from the most first sector considering cell(LayerBreak is between cell and cell). And description of LayerBreak is appropriately added in IFO.
....And sector size of L1 is different between 3 ways.

[Sorry, blue letter is part later edited.]

r0lZ

19th June 2005, 12:03

I have verified my code, and it's true that the Interleaved flag was not checked. It is now. The interleaved cells of Matrix are not shown in the list anymore.

If you want to try: beta 9 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta9.zip).

frank

19th June 2005, 12:05

@rOlZ
I've found the difference of iso calculations PgcEdit - IsoBuster, and updated the values in my posting (#104 page before).
It seems there is an issue with the footer constant in procedure burn.tcl.
The values differ exactly by that 151 sectors.

How can I switch PgcEdit to config debug mode?
I want to see some more informations only showed in this mode.

jinjin_jp

19th June 2005, 12:12

r0lZ

19th June 2005, 18:20

@Frank: Right, PgcEdit assumes that the footer added by mkisofs is always 151 sectors long. This footer needs to be added to the compilation size.

How can I switch PgcEdit to config debug mode?
I want to see some more informations only showed in this mode.Control-Middle-Double-Click (!) on the PGC Selector drop-down menubutton (the one labelled "PGC") to open the console, and type set ::config(debug) 1The debug mode is saved with your options, so, to turn it off, you must set it back to 0. Leaving it on may slow down some routines.

Note that I have removed some of the infos availables in debug mode, but most of them are now visible in the GUI. I will remove all the infos in the final version, to be released soon. So, if you think there is still a problem, please check it and report it here as soon as possible. Thanks.

frank

19th June 2005, 19:53

Thanks for your hints, rOlZ :)

I never realized the added footage but now I look at my burned DVD and see the session size = 3677984 sectors (+151)! That's exactly what PgcEdit calculated as to burn (modulo 16).

I think the session size includes the Lead-out Zone (~150 sectors) that has to be written by the application. Since leadout does not count as data there is no need to add it. The Lead-out Zone has a reserved area on dvd (0.5...1 mm after Data Zone).
Now I haven't the specs here but I will look.

r0lZ

19th June 2005, 20:13

I'm not sure the 151 sectors are the lead-out, since when the burn is finished, DVD Decrypter adds a message about writing the lead-out.
However, I don't know for sure if the footer must be included in the compilation size, but I prefer to do so, to be safe. Anyway, loosing 151 sectors is not much.

frank

19th June 2005, 21:19

mkisofs doesn't know what burning program used. This lead-out footage increases the read out stability, and doesn't matter.
I looked into the 151 appended sectors: There are zeroes with a sector counter. After that dvd access is denied.

r0lZ

19th June 2005, 21:51

OK. But these sectors are in the ISO. It's a fact.
If I don't count them, and the user selects a LB that is before or just at the middle of the ISO, then, after the padding of L0, the second half (including the 151 sectors) will be larger than the first one. What will be the behaviour of DVDD in this case?

I think it's safer to count them. If DVDD is smart enough to disgard them, it will simply add 151 additional padding sectors in L1.

Of course, if you are sure that DVDD will drop the footer anyway, I may safely remove the 151 sectors from the count. In some rare cases, that may be sufficient to include one additional valid cell in the list. But are you really sure?

Also, the user may want to burn the ISO with another burner. And it's difficult to know how every burner will handle this case.

frank

19th June 2005, 22:22

Yes, yes you did it right! I see.

I now found it in mkisofs doc.
OPTION -pad
Pad the end of the whole image by 150 sectors (300 kB).
...
The padding is needed as many operating systems (e.g. Linux) implement read ahead bugs in their file system I/O. These bugs result in read errors on one or more files that are located at the end of a track. They are usually present when the CD is written in Track at Once mode or when the disk is written as mixed mode CD where an audio track follows the data track.

To avoid problems with I/O error on the last file on the file system, the -pad option has been made the default.You can switch off it with option -no-pad. I would do so.
Since DVD-ROMs don't have such footage, DVDD writes in SAO (side at once), and hardware players don't use a ISO file system.
[Edit]

r0lZ

19th June 2005, 22:37

Oh, yes, I remember this part of the mkisofs doc.
But I don't think I will remove the padding sectors, because I will probably implement the Burn DVD function under Linux and Mac as well (although it will probably be limited to the ISO creation.)
And remember is is possible to include DVD-ROM files in the compilation.
And there are some standalone players (able to show DivX movies) that are based on Linux Embedded. I have an old KISS player running Linux.

Also, I think that hardware players do use the UDF filesystem.

frank

20th June 2005, 18:24

Also, I think that hardware players do use the UDF filesystem. Sorry, a typo. :rolleyes: I know, hw players don't use ISO system, they use a subset of UDF 1.02. And mkisofs generates the UDF bridge format.

mkisofs is part of Linux cdrtools by Jörg Schilling. As you can see the options refer to CD (ISO 9660) not DVD, isn't it? VIDEO DVDs are not burned as TAO, or as mixed mode CD...
The 150 sectors prevent read errors on such (ISO) CDs on Linux.
But how does Linux refer to DVDs? I think Linux uses UDF drivers.
So the 150 sectors have no meaning in our case, pressed DVD-ROM also don't have such appendix.
I never heard that Linux freaks had problems with DVD playing on last file.

But you can let it be as it is, it doesn't matter.

blutach

20th June 2005, 23:07

Better leave what's workig and be safe IMHO.

And yes, (compliant) players always use 1.02 UDF. ISO could be used on older window$ based systems that have no native UDF reader - eg W98. So need that too. I haven't seen anyone who knows about these things, argue against the UDF1.02/ISO bridge (here they come now I bet :))

Regards

r0lZ

21st June 2005, 09:05

In beta 10 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta10.zip), I have removed the padding sectors. Seems some older versions of mkisofs don't have this option by default, and also, in v 2.01, the description of the -pad option differ when you type mkisofs -help: -pad Pad output to a multiple of 32k (default)
-no-pad Do not pad output to a multiple of 32kObviously, this is an old message. I think therefore that it is better to avoid this option.

Note that there is still one padding sector added at the end of the ISO. (Seems logical: the -pad option adds 150 sectors. But with this option ON, there are 151 padding sectors effectively added. So, with the -no-pad option, there is 1 remaining sector.)

BTW, in Beta 10, the creation of the ISO is supported under Linux, apparently without problem. But I cannot find a recent version of mkisofs for Mac OSX. V1.15a36 seems to be the last version available for Mac. But this version do not handle the gaps properly. Pitty. If somebody has a newer version of mkisofs for mac, please let me know.

I will add the mkisofs version number in the log, and specify that v2.01 or more must be used.

blutach

21st June 2005, 12:32

I think this version is available on coujo's site under ImgToolsClassic 0.91.5

Regards

r0lZ

21st June 2005, 13:16

Yes. It is the version that is downloaded if you click on the Download ImgTool Classic button in the Burn DVD Setup dialog.
But this version doesn't exists under Mac OSX yet.

r0lZ

21st June 2005, 13:23

Beta 11 (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta11.zip) is available.

The main change is the Create ISO function, now available also under Linux. See this thread (http://forum.doom9.org/showthread.php?t=96194).

If you want to check beta 11 under Windows, download this version: PgcEdit_winexe_0.6.0beta11.zip (http://www.videohelp.com/~r0lZ/pgcedit/beta/PgcEdit_winexe_0.6.0beta11.zip).
Not much has changed under Windows, except that I have removed the 150 padding sectors added by default by mkisofs, and I have added a button to check the mkisofs version number in the Burn Setup dialog.