View Full Version : LBA question
jfcarbel
25th September 2003, 08:34
I am entertaining the idea of writing a DirectShow source filter/splitter that will keep track of LBA as it feeds frames and will allow seeking by LBA.
I am not very familiar with LBA except that it stands for Logical Block Address and is used to jump to a filepos. And its "the sector number relative to the start of the fileset -mpuCoder"
My Questions:
Does an LBA change if a file(s) are moved to another drive or directory? How does this apply to a DVD you may insert into a drive?
Thats is, does the filesets start LBA differ if its location moves?
Can ASPI or IOCTL be used to get the LBAs from both hard drive and DVD? What are the best code examples of this out there? (think vStrip is one)
Any web resources/tutorials explaining LBA are welcome. Thanks.
doomDVD
25th September 2003, 16:58
To get the LBA from a DVD you need to create yourself a UDF parser i would recomend that you have a look at vstrip by maven.
when working from the HD you dont realy need anything special to get the LBA for a file since you can just read the file using standard C IO functions and assume that the files LBA always starts at 0
for example:
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
//
// this will only work per file.
//
void OpenDVDFile(char *dvdfile)
{
if((dvdf = fopen(dvdfile, "rb")) == NULL)
{
//error
}
else
{
fseek(dvdf, 0, SEEK_END);
START_LBA = 0x00;
END_LBA = ftell(dvdf);
fseek(dvdf, 0, SEEK_SET);
fclose(dvdf);
}
}
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> yes the start and LBAs for the files will change as you move the files around on the hard drive. as the files will be appended onto available addresses on the disk
regards
doomDVD
jfcarbel
25th September 2003, 17:24
I thought both DVDDecrypter and vStrip use ASPI to read even from a DVD drive. Am I wrong? Are there strong benefits to using UDF over ASPI?
doomDVD
25th September 2003, 18:05
yes DVDdecrypter and Vstrip both use aspi to read from a DVDdisk. but aspi is also used within a udf parser. and a udf parser is needed to get the LBA for a file contained on the disk.
jfcarbel
25th September 2003, 18:39
but aspi is also used within a udf parser
Okay I think I understand now. A UDF parser uses ASPI to access the DVD on the drive. And a UDF parser gets me the LBA of files.
Sounds like you are writing some UDF parser already, are you using vStrip code as an example?
Do you have any small testing programs that you wrote, these would be a good learning tool for me, since my C++ is very rusty and vStrip has lots of code.
Also confusing to me is I read somewhere that the VOBs in a Title set appear as one large file. Is this done by just making the startLBA = previous VOB endLBA+1?
Thanks for your help.
Guest
26th September 2003, 04:02
LBA as a file location on a disk is not the same as LBA as an offset into a given file starting at 0!
For multi-VOB loads, DVD2AVI treats them as individual files each beginning with LBA 0. When a file reaches EOF, it sets the next file as active and resets the LBA to 0.
jfcarbel
26th September 2003, 06:11
So when using UDF parsing on a DVD is the LBA start from 0 for each VOB in a title set?
I understand why it would be 0 for regular files in a file system. But I want to confirm about the UDF on a DVD. And then its on to looking at the vStrip code :)
Thanks neuron and doomDVD
doomDVD
26th September 2003, 15:58
to understand the LBAs based on a DVD disk imagine this:
VTS_01_0: Start_LBA := 0, End_LBA := 1000 --
VTS_01_1: Start_LBA := 1000, End_LBA := 2000 |-> ex.
VTS_01_2: Start_LBA := 2000, End_LBA := 3000 --
every file including IFOs, BUPs, VOBs, and other files the disk producer has placed on the disk will have its own unique address.
it helps to think of the disk as one huge file, and the LBAs are just offsets into that file.
hope this helps,
kind regards
doomDVD
jfcarbel
26th September 2003, 22:33
doomDVD - Thanks.
The example did it for me. I get it all now. So it is just files on the hard drive that will all have a start LBA of 0.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.