2006-07-29: Keith Bennett dixit:
> On Sat, Jul 29, 2006, EV wrote:
> > Mp3s may have only trailer tag areas (no header tags).
> 
> Really? That's insane! Can't you just pretend that they don't
> exist and leave them unsupported? I don't own any MP3s so I'd
> be fine with that! :)

May be I was not clear enough.  AFAIK, mp3s must have a tag area.  
But where it goes and which version of id3 tag you use are
optional.  You may have just an id3v1 trailer or an id3v2
followed by id3v1 trailer or just an id3v2 header.
 
> > [...] However there is a little difficulty:  to avoid
> > breaking reentrant operation, we need a different temporary
> > filename for each ongoing open-write call.  And the name must
> > be kept in the stack memory (we might need to open the file
> > after the first write chunk and close it upon the clossing
> > call).
> 
> Should be easy enough. I presume that FUSE passes around
> pointers for that kind of thing. Are you sure that the name has
> to be passed around and not just a file descriptor?

Yeah, you can pass a file descriptor, sure.
 
> > > [...] No, I meant the file that is being written *to*. 
> > This is what I was meaning too!  of course, the *from* file
> > may just be unexisting...
> > > We know that because we are the ones doing the writing!
> > Yes but, as I said, I've not found how to refer to a file created
> > by FUSE/lkarmafs from within lkarmafs -- yes, I know it is quite
> > strange...  You can easyly access files outside the lkarmafs
> > mount-point but not those within the mount-point tree.
> 
> Now I'm really confused. You mean the fids0/_000??/??0 file?

No, I am talking about the virtual files posted by lkarmafs 
itself.

> > [...] Not really.  Once a file appears under the (USB or
> > Ethernet))  lkarmafs-mounted directory structure, you can run
> > e.g. id3v2 to get the tags, but only from a process different
> > from the one running lkarmafs.
> 
> Oh, you mean that the karma pearl interface will return the
> actual tag info from a query rather than the the fake version
> that you wrote? 

No.

> If that's the case then implementation is easy and you don't
> have to deal with any of this temporary file garbage. Surely
> that can't be the case, though. If this was true then why
> wouldn't the karma just use this info itself?

Right!  As you say, this is not the case.

> If that's not what you are talking about then I am utterly
> confused again. Surely all id3v2 calls are done via lkarmafs
> which in turn just queries the karma.  Please explain.

I know it is confusing... and my English surely adds to it ;)  

Let's try again.  Let myBestTune.mp3 be a tune file in your host.
Using, e.g. 'id3v2 -l myBestTune.mp3', you get: Title: "my best
title", Artist: "my prefered artist", Album: "the best one", etc.

Now, using e.g. the -T lkarmafs option you can upload this file
so that, by mounting the RK with lkarmafs -G, you get something
like "mnt/tune/A/B/xyz.mp3".  The RK database (both smalldb and
the xx1 file) contains artist="A", source="B", title="xyz" and
codec="mp3".  But you can still run 'id3v2 -l mnt/tune/A/B/x.mp3'
and get:  Title: "my best title", Artist: "my prefered artist",
Album: "the best one", etc.

That is, although the properties in the RK db are typically
extracted (by riocp, rmml, etc.) from the id3 tags, the tags
themselves are held intact where they used to be in the original
file:  xx0 files are just exact copies of the original ones.

Going back to the lkarmafs tag extracting problem, once you have 
a lkarmafs-mounted tune, you can get the tags contained in the 
file itself by using, e.g., taglib or just running id3v2.

>From this point of view, our lkarmafs tag extracting problem
apears to be easyly solvable by calling the taglib library with
the (virtual) pathname of the file lkarmafs has just produced.  
The strange problem is that this seems impossible from within the
process running lkarmafs...

Hope this lengthy explanation doesn't add even more confusion ;)
Regards,
EV.


-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-karma-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-karma-devel

Reply via email to