h a l f b a k e r yThe Out-of-Focus Group.
add, search, annotate, link, view, overview, recent, by name, random
news, help, about, links, report a problem
browse anonymously,
or get an account
and write.
register,
|
|
|
On a CD-R, it is possible to have one file appear in multiple places in the directory structure and yet only be stored once on the disk. While this could be used in other situations as well, one possible application would be in setting up directories of MP3 files.
As an example, I have a CD entitled
Songs of the Cat. Some songs are sung by Garrison Keillor, some by Frederica von Stade, and some by both. Sometimes I may just be in the mood for Mr. Keillor's, sometimes just Ms. Stade's, and sometimes I'd want them all.
One way to accomplish this would be to have three directories: one with all the songs, one with Keillor's, and one with Stade's. Unfortunately, just plopping the files on the disk this way would waste a fair amount of space. If all I wanted was that one CD, this wouldn't be a problem, but I'd like to have a dozen or so overlapping playlists including songs from a dozen or so CD's; storing all the files separately would probably take over a gig.
It is possible, however, using Adaptec/Roxio Easy CD Creator, to set the directories up like that without having to store multiple copies of each file. Unfortunately, the only way I've found to do so is a real pain in the tush.
What one must do is drag one copy each of all the desired files on the CD and burn it. Then import that session and copy and paste the files within the CD into the desired directory structure. Then burn the second session.
I've tried this. It works. It's also a real pain.
What would be much nicer would be if the CD burner software could be told that when a file named "xxxx.cdlink" is dragged onto the CD, the burner should read from that file the path of a real file to use. If the specified real file does not exist on the CD, it will be added; if it does exist, only a directory entry (pointing to the other file) will be added.
In this way, it would be possible to have on a hard drive many directories each containing a desired set of 'files' [actually just links to files] and just drag onto a CD whatever set of files one wanted to use.
Any idea if any software supports such a concept?
On a related note, do any free or reasonably-priced burner packages support scripting using text files? Such abilities would make it easier to set up certain kinds of disks rather than having to locate, drag, and rename files in the graphical tree.
[link]
|
| |
Dude. It's a neat idea, but you've managed to make every CD/DVD player in the world obsolete - just so you can have multiple playlists on a single CD? |
|
| |
Give your snail mail address and I'll send you some blanks. Hell, I'll send you $15 and you can buy a 100 of 'em. |
|
| |
phoenix: You miss the point: this doesn't make players obsolete. Any player which can accommodate multi-session CD's should be able to read CD's created via this technique. |
|
| |
Each directory entry on a CD contains the sector number where the file starts. It is possible to create a CD in which multiple directory entries contain the same starting sector number; each such directory entry will appear to contain a copy of the file. |
|
| |
There is an extension to the ISO9660 CD format called Rock Ridge, supported by most Unix machines and CD burning programmes which allows this. Just create symlinks on your hard disc and they'll be transferred onto the CD. Most Unix CD burning software can also be scripted, too. I see no reason why Windows CD software shouldn't support similar features. |
|
| |
//There is an extension to the ISO9660 CD format called Rock Ridge, supported by most Unix machines and CD burning programmes which allows this.// |
|
| |
The Joliet format already supports the aliasing without need for any extensions beyond multi-session support. The only difficulty is in getting the PC-side software to set things up nicely. |
|
| |
//I see no reason why Windows CD software shouldn't support similar features.// |
|
| |
Aside from the fact that Windows doesn't support symbolic links? |
|
| |
Every day it seems I feel more and more tempted to install Linux on my machine. Wonder when I'll break down and 'just do it'? |
|
| |
So are we talking about playing these things in a computer (where the function can be handled by software) or CD/DVD players (where it can't)? Apples and Oranges. |
|
| |
phoenix: What am I not making clear here? You burn them on a computer, and play them on a standalone MP3 player. The idea here is for an enhancement for the compuer-side software which would make the **EXISTING** MP3 players more useful. |
|
| |
If multiple directory entries on a CD point to the same physical file, any MP3 player which supports multi-session disks will see those as separate files even though they take no more disk space than a single file. |
|
| |
Thus, one could create a disk with a directory for each desired play list; since having a file appear on multiple play lists would not require multiple copies to appear on the disk, one could have a large number of playlists on disk; the only restriction would be if the player is limitted to a certain total number of files. |
|
| |
If you have Roxio/Adapted Easy CD Creator and an MP3 player, try this: create a directory on a CD called "All". If you're using a 700MB CD, throw 650 megs of music into it. Then burn. |
|
| |
Then import session, copy/paste the folder a bunch of times, giving the other copies names descriptive of playlists. Then go into each such playlist directory and delete all the files you don't want in that playlist. |
|
| |
When you burn the second session on the CD, may end up with a disk that seems to have over a gig of stuff, yet it fits on the CD. If your player can handle multi-session disks, you should be able to select any 'playlist directory' and have the player run the songs from that playlist. |
|
| |
This method works with an off-the-shelf MP3 player; I've tried it. The major problem is that it's a pain in the tush on the PC side to set up play lists this way. My immediate goal is to fix that. Aliasing could also have other benefits, but the playlist thing would be my first use for it. |
|
| |
//Then import session, copy/paste the folder a bunch of times, giving the other copies names descriptive of playlists. Then go into each such playlist directory and delete all the files you don't want in that playlist.//I have Adaptec/Roxio - I use Roxio for most part - never had a burn fail. That said, how can I burn more onto a disc that is freshly burned and already nearly full? |
|
| |
thumbwax: Let me try to explain this, since enough people misunderstand it that I'm getting fishboned for some reason. |
|
| |
Suppose I create a CD with one really huge 600MB file--say, a copy of all the regulations related to pork bellies in the U.S. I call this file "porkbellieregs.txt" and burn the CD. |
|
| |
After burning the CD, I realize I misspelled "belly", so I import session, click the file, and rename it to "porkbellyregs.txt". |
|
| |
Even though there used not to exist a file called "porkbellyregs.txt", I have not added any data to the CD. I merely created in the current session a directory entry for file "porkbellyregs.txt" which refers to the already-existing file. |
|
| |
If I were to hit "copy" on the imported file, rename the original to something else, and then hit "paste", two copies of the file would show up in the disk directory. In fact, though, when I hit burn I wouldn't be burning ANY copies of that file. I'd merely be burning a directory which contains two references to the already existing copy. If I wanted to copy/rename/paste some more, I could create dozen more such "files" before burning; a directory of the disk would show 14 files of 600MB each totalling 8.4GB. |
|
| |
Having 14 differently-named "copies" of the same file in the same directory would not generally be useful, but the same technique works if the files are placed in different directories. |
|
| |
In many operating systems, having multiple directory entries pointing to the same part of the disk is a very bad thing, since deleting any one of the "files" would cause the space used by all of them to be freed. On a CD-ROM, however, space can never be freed or re-used, so that's a non-issue. |
|
| |
I don't understand the fishbones either. |
|
| |
Supercat, I have spent the last 2 years trying to figure out what you have just mentioned (creating a multisession cd for playlists). Last week, I just gave up and I was going to hack mkisofs to do what you just mentioned. And then, I came across your post, and there was light :) |
|
| |
Thank you, thank you. Did I say Thank You!!
MT |
|
| |
[dspguy]: So how does one /conveniently/ create the necessary aliases to make this work usefully? |
|
| |
OK, so your ultimate desire is to implement hard linking (multiple directory entries, one physical copy of the file, directory entries point directly to the file data not each other) in a CD filesystem. You want the layout editor software to natively support hard linking in such a way that it is painless to use this feature, so you won't be forced to use your hackish multisession CD workaround. (Nice hack, btw) |
|
| |
For somebody with the source code for a decent layout editor, that's a reasonably easy wish to grant. It would only require minor modifications to an existing layout editor to supply the user with an 'insert link' function. The program could implement that function by prompting the user for the location (in the layout) of an existing copy of the file to be linked. The layout engine will actually use symbolic links internally to support this function, and will treat all symlinks as zero-length files for purposes of calculating free space remaining. |
|
| |
When the layout is compiled into the actual CD image, the symbolic links are resolved into the starting address of the single instance of the data they point to. Each directory entry in the image is then written as if it were the only one pointing to that single instance of the data. That CD image can be burned onto a disc in a single session. Bingo! You now have a single-session CD which uses hard linking. You don't need Rock Ridge and it's Microsoft friendly. |
|
| |
You can even allow users to link directories (they are just files themselves, after all) and have all kinds of fun. Just be careful not to create any infinite reference loops in the directory structure. |
|
| |
By the way, you might want to send a letter to Adaptec(Roxio) and let them know that you want the next version of EasyCD Creator to include native hard link support. If you explain why you want it and include an overview of how it could be implemented (like in my anno above) then they will probably listen. If enough other people also write letters asking for this feature, they might even act. |
|
| |
//You can even allow users to link directories (they are just files themselves, after all) and have all kinds of fun. Just be careful not to create any infinite reference loops in the directory structure.// |
|
| |
On a CD, where are directories stored relative to files? On many portable CD-ROM players, I suspect disks would start up most quickly if all the directories were grouped together at the start of the disk, but by the sound of my player's head gronking over the disk on startup I'd guess they're stored closer to files. I'd guess that having them nearer files would make access on most computers faster, but having them grouped together would make access faster on devices which preload the directory structure. Does anyone know if this would be possible? |
|
| |
//You can even allow users to link directories (they are just files themselves, after all) and have all kinds of fun. Just be careful not to create any infinite reference loops in the directory structure.// |
|
| |
On a CD, where are directories stored relative to files? On many portable CD-ROM players, I suspect disks would start up most quickly if all the directories were grouped together at the start of the disk, but by the sound of my player's head gronking over the disk on startup I'd guess they're stored closer to files. I'd guess that having them nearer files would make access on most computers faster, but having them grouped together would make access faster on devices which preload the directory structure. Does anyone know if this would be possible? |
|
| |
I believe iso9660 supports hardlinks - though, there's no easy way to create them in windows - use mkisofs |
|
| |
and, [supercat], multiple directory entries pointing at the same part of the disk works fine on most filesystems (any unix or NTFS) |
|
| |