| Blu-ray disc burn breakthrough |
|
Published: 14th Apr 2008, 19:45:20GMT Source: drobe.co.uk
By the Drobe news desk
|
| Page 1 of 1 |
|
| 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."
 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 explainedRelated articles
Performance boosting disc cache developed
This article has been linked to, or is available in the following formats:
|
| |
|
JohnB (+2.1)
14/4/08 8:12PM |
Congratulations to Steffen - and it's good to see continued development of CDVDBurn. |
DaveC (+2.0)
15/4/08 12:22AM |
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 |
Pete (+2.0)
15/4/08 10:04AM |
Brilliant, I want it. |
rmac (+2.0)
15/4/08 10:16AM |
Once again a great achievement. My money is ready. |
jymbob  (+1.0)
15/4/08 11:42AM |
So is the next version going to be called CDVDBluRn? Still within the 10 character limit! |
sascott (+1.0)
15/4/08 2:57PM |
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
15/4/08 2:58PM |
NutBurner!  |
sascott
15/4/08 2:59PM |
I'll get my coat... |
jess
15/4/08 4:32PM |
!HuburN |
mrmac
15/4/08 5:42PM |
What about simply RiscBurn
Well done on the achivements |
hzn (+1.0)
15/4/08 5:57PM |
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? |
lym (+1.0)
15/4/08 6:25PM |
Why not just !Burn? Like !Paint, !Edit, etc. It's the RISC OS way. |
sbellon (+3.0)
16/4/08 9:06AM |
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.  |
hzn (+3.0)
16/4/08 11:51AM |
True !Burn is better than !AnyBurn ... avoids the app to be put in the same tray as AnyDVD |
jms (+1.0)
17/4/08 8:23AM |
!OptiBurn as it burns a variety of OPTIcal discs? |
hubersn (+1.0)
17/4/08 10:57AM |
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 |
flibble
17/4/08 7:45PM |
!IAmOnFire |
BrianH
18/4/08 12:13AM |
Me/ Throws bucket of water over Flibble... |
IvanDobski
18/4/08 9:25AM |
!Pyromania |
jess (+0.1)
18/4/08 10:19AM |
"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. |
rjek
18/4/08 4:41PM |
In reply to 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. |
jess
20/4/08 9:20AM |
In reply to 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) |
hzn
20/4/08 10:26AM |
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. |
rjek
20/4/08 11:51AM |
In reply to Jess:
Why do a hack when you can do it properly? And no, it wouldn't be viable. |
jess
20/4/08 1:23PM |
In reply to hzn:
I'm pretty sure that a new (or at least extended) API would be needed to fully use files bigger than 2GB.
In reply to 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? |
rjek
20/4/08 6:14PM |
In reply to 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. |
| Please log in to post a new comment |
|
|
|
|
Show your support and appreciation of Drobe launchpad by donating a little money to cover our running costs!
|
|
