Blu-ray disc burn breakthrough | RISC OS news and information from Drobe


Beta! \| About us \| Contact \| Submit news \| RSS \| Twitter	Webspace \| Tech docs \| Downloads \| BBC Micro \| Gallery \| Wallpaper

Blu-ray disc burn breakthrough

Published: 14th Apr 2008, 19:45:20.

Up to 25GB storage on one DVD-sized disc [Updated]

Programmer Steffen Huber says he has managed to burn a Blu-ray disc using his Iyonix and RISC OS 5. Steffen, who develops the popular CD and DVD-writing package CDVDBurn, announced his breakthrough during the early hours of today.

Blu-ray discs are the same physical size as normal CDs and DVDs but can cram on far more data - as much as 25GB for single-layer and 50GB on dual-layer discs - by using blue-violet lasers. This impressive storage capacity makes the discs useful for backing up large amounts of data. The Blu-ray design also successfully saw off HD DVD in the recent high-definition optical disc format war.

Today, Steffen said he has been able to write data onto a re-writable Blu-ray disc (BD-RE) and successfully pull the information back off intact using an in-development version of his CDVDBurn software. He admitted he hasn't tried using a write-once Blu-ray disc (BD-R), pictured here.

Steffen said: "I am happy to report the first milestone on my way to implementing Blu-ray support on RISC OS.

"I have just finished formatting and writing the very first BD-RE (Blu-ray Rewritable Medium) with an extended version of CDVDBurn using an Iyonix and an LG GGW-H20L drive. And what is probably most important, the CDVDBurn extractor was able to read the data back without failure."

He added: "The code needs a bit of tidying up, but it seems to work fine so far. It is similar to DVD-RAM writing, but the error correction options especially are much more numerous and I have not decided yet which parameters should be user-adjustable and which should not.

"I also have no experience with BD-R yet and also not with the double-layer variants. Having experience with more than one device wouldn't be a bad idea, too."

Blu-ray logo

Steffen said he used an AD0006 IDE ATAPI-to-SATA interface adapter to hook his LG drive up to his Iyonix. He also hopes to add DVD+R double-layer support for the next version of CDVDBurn and is currently working out why the DVD+R writing support "sometimes seems to fail".

CDFS work
He added that he is also beavering away to address and fix issues within the CDFSSoftATAPI soft-loadable CDFS driver, the source code of which was released under the RISC OS Open shared-source scheme. He said the driver "has some well-known shortcomings that makes it unsuitable to successfully drive, for example, the LG DVD writers when trying to read DVDs".

Steffen said: "This driver work is a stop-gap measure because my full-blown universal supports-every-drive-under-the-sun driver will take a bit longer to finish. I intend to release the fixed work as free-for-everyone, and the completely new driver under a donate-if-you-like-it scheme."

It's understood Steffen is now throughly testing his new Blu-ray support code in CDVDBurn.

Update at 23:09 15/4/2008
We threw a few queries at Steffen and here's how he answered them:

Drobe: When do you plan to release the new Blu-ray supporting CDVDBurn?
Steffen: "No idea - it depends on how much free time I get and how quick the necessary fixes for the pending bugs are. I am aiming for a Wakefield release. Unfortunately, I can't be there but I'll still try to meet the deadline."

Are you going to call it CDVDBlurn?
"How about CDVDBurn Blue Edition?"

So, can RISC OS users burn, say, a full 25GB of data onto a Blu-ray single-layer disc?
"Yes. Just like they now can use the full 4.7GB on a DVD+R/+RW/-RAM with CDVDBurn."

There's no issues with regard to RISC OS's inability to handle disc image files greater than 2GB in size?
"No problem, since there is no image file system implemented. For disc images bigger than 2GB, CDVDBurn creates a set of 2GB files in a directory and handles it transparently as a big file."

The disc when written to and when read back isn't treated like a fairly modest-sized hard disc, then?
"No, the disc is treated like a large CD-R(W). The operation is unchanged from the classic CD mastering work flow: put the layout together, create the disc image, write the disc image. The writing process is strictly sequential.

"In other words, it is not treated as a hard disc-like thing because CDVDBurn does not implement a filing system.

"To sensibly implement a true filing system, it would really need UDF. I am currently talking to another developer who wants to have a go at implementing a Filecore file system for DVD-RAM (and consequently for other random access media like DVD+RW and BD-RE). We'll see how this will work out."

Links
Hubersn Software
What is Blu-ray?
BD-R and BD-RE explained

Discussion

Viewing threaded comments | View comments unthreaded, listed by date | Skip to the end

Congratulations to Steffen - and it's good to see continued development of CDVDBurn.

JohnB on 14/4/08 8:12PM [ Reply | Permalink | Report ]

That is fantastic! I never thought Blu-Ray would be tackled by RISC OS.

That really is a landmark achievement - Well Done Steffen.

Cheers, Dave C

DaveC on 15/4/08 12:22AM [ Reply | Permalink | Report ]

Brilliant, I want it.

Pete on 15/4/08 10:04AM [ Reply | Permalink | Report ]

Once again a great achievement. My money is ready.

rmac on 15/4/08 10:16AM [ Reply | Permalink | Report ]

So is the next version going to be called CDVDBluRn? Still within the 10 character limit!

jymbob on 15/4/08 11:42AM [ Reply | Permalink | Report ]

Why don't we have a competition to suggest a more appropriate name? BluNutBurn comes to mind!

As an aside, Steffen gave me a lot of valuable assistance during my early days at Acorn User, when I was working on the 97 and 98 cover CDs, and writing articles about cd burning. He knows his stuff. Even so, today's news is a stunning achievement. Well done Steffen!

sascott on 15/4/08 2:57PM [ Reply | Permalink | Report ]

NutBurner! :-p

sascott on 15/4/08 2:58PM [ Reply | Permalink | Report ]

I'll get my coat...

sascott on 15/4/08 2:59PM [ Reply | Permalink | Report ]

!HuburN

jess on 15/4/08 4:32PM [ Reply | Permalink | Report ]

What about simply RiscBurn

Well done on the achivements

mrmac on 15/4/08 5:42PM [ Reply | Permalink | Report ]

Well, I must admit that I am not surprised ... it simply fits Steffens style to do this kind of work :-)

OK, serious: Great including the on-the-fly-test of an IDE-to-SATA-converter.

As for the name how about a simple !AnyBurn?

hzn on 15/4/08 5:57PM [ Reply | Permalink | Report ]

Why not just !Burn? Like !Paint, !Edit, etc. It's the RISC OS way.

lym on 15/4/08 6:25PM [ Reply | Permalink | Report ]

Yes, I was thinking about !Burn all the time as well, it's the "RISC OS way", indeed. And as there aren't many other competitive products for burning CDs, DVDs, etc. on RISC OS anyway, it's the de-facto standard product and can thus proudly call itself !Burn. ;-)

sbellon on 16/4/08 9:06AM [ Reply | Permalink | Report ]

True !Burn is better than !AnyBurn ... avoids the app to be put in the same tray as AnyDVD :-)

hzn on 16/4/08 11:51AM [ Reply | Permalink | Report ]

!OptiBurn as it burns a variety of OPTIcal discs?

jms on 17/4/08 8:23AM [ Reply | Permalink | Report ]

Thank you all for your creativity ;-)

Just calling it Burn is an idea I like very much. However, I think for the time being it will just keep its old name. I don't intend to sell the Blu-Ray-capable upgrade anyway, since I don't want to force users into paying for stuff they don't use - and I guess the number of users wanting to invest in a Blu-Ray writer will be very low. However, I will introduce a donation scheme for new features so that users can voluntarily donate for the new features they find valuable.

Much easier than changing the app's name whenever a new feature is introduced ;-)

hubersn on 17/4/08 10:57AM [ Reply | Permalink | Report ]

!IAmOnFire

flibble on 17/4/08 7:45PM [ Reply | Permalink | Report ]

Me/ Throws bucket of water over Flibble...

BrianH on 18/4/08 12:13AM [ Reply | Permalink | Report ]

!Pyromania

IvanDobski on 18/4/08 9:25AM [ Reply | Permalink | Report ]

"No problem, since there is no image file system implemented. For disc images bigger than 2GB, CDVDBurn creates a set of 2GB files in a directory and handles it transparently as a big file."

Would it not be a good idea for ROL and ROOL to define an API to access big files? Until it is implemented in real filesystems, it could be faked by a module that works like the above.

jess on 18/4/08 10:19AM [ Reply | Permalink | Report ]

jess: The faking sounds like a hack: and won't let you access pre-existing large files over, say, NFS. And yes - they should define an API - at the same time as redefining the entire API and ABI for the file system stack.

rjek on 18/4/08 4:41PM [ Reply | Permalink | Report ]

rjek: It would be a hack, but at least it would mean any programs could use the same hack (instead of implementing their own), via an API, which could be done properly in a future update of the OS.

Would it be viable for additional filesystems to support such an API directly, rather than relying on the OS? (The hack would obviously need a passthrough system)

jess on 20/4/08 9:20AM [ Reply | Permalink | Report ]

No API, please but the real filingsystem supporting more than 2GB - or make DOSFS a real filingsystem and not an image filing system so that you can use current USB sticks.

hzn on 20/4/08 10:26AM [ Reply | Permalink | Report ]

Jess: Why do a hack when you can do it properly? And no, it wouldn't be viable.

rjek on 20/4/08 11:51AM [ Reply | Permalink | Report ]

hzn: I'm pretty sure that a new (or at least extended) API would be needed to fully use files bigger than 2GB. rjek: In the absence of a generic greater than 2GB support, programs that need the support will have to provide a hack internally. That hack would then need to be bypassed when systems that provide the support appear. If a module were produced that faked proper large file support, any applications that used it would not require changes when the OS does the job properly itself. It would also provide support for old systems, just in the same way longfiles does.

If a new filesystem were released tomorrow, how many people would reformat their system to use it?

jess on 20/4/08 1:23PM [ Reply | Permalink | Report ]

jess: Large files isn't a file system issue: it's an API issue. We already have file systems that support large files, if only RISC OS provided an API to access them. For example, UDF on CD/DVDs, FAT on USB sticks, NFS and SMB/CIFS over a network.

You seem to be obsessed by implementing hacks, rather than implementing things properly. Don't do that. RISC OS has too many hacks that were only meant to be stopgaps already.

rjek on 20/4/08 6:14PM [ Reply | Permalink | Report ]

Please login before posting a comment. Use the form on the right to do so or create a free account.

Create a new account
Forgot your password?

Search this website

This week's poll

Recent developments have left me feeling...

Assured ROS will appear on new hardware		55%
Pleased OS desktop features are being developed		10%
ROL and ROOL will eventually kiss and make up		5%
App developments are critical		10%
Dave Holden sleeps easy at night		19%

Discuss this | Archives