On Sat, Jul 29, 2006, EV wrote: > > Hmm. My problem with all this is that I don't use lkarmafs very > > much so I have little motivation to fix things. [...] However, > > I'm not a *completely* selfish person so I might be able to > > spare a little time looking into lkarmafs matters! :) > > Undrestood. It was just an idea...
No problem. It was me that was asking for suggestions after all! > > Well vorbis is a streaming format by design, so the libraries > > can get this information from the first chunk. Not sure how big Actually I seem to be wrong about this. Certainly as far as taglib is concerned, at least. > I don't know about vorbis, but mp3 files may have a header, a > triler or both. There is no essential problem with the trailer > tags, as we only need the duration (and/or other tags) upon > clossing the RK file. So, in principle, this would be doable if > there existed some library for decoding id3 tags from memory > buffers -- rather than from (whole) files. I should learn to actually read some code before making rash comments. You are right. Most of the libraries out there want you to provide them with a filename which makes fancy buffer techniques impossible. Very bad design IMNSHO. Fortunately, we can rely on /dev/shm existing on most distros, so temporary files can be copied there without *too* much overhead. Still a bit ugly, though. > There is an additional problem with variable frame rate mp3s. > The exact duration of these files seems difficult to estimate > whthout going through the entire file! (I'd be content with an > approximate estimate, though). I did a little experimenting and taglib seems work okay with just the header which always seems to be much smaller than 4k. The easy method would just be to write a temporary file into /dev/shm on the first write call and pass this along to taglib. It wont be able to work out the track duration but it will give you the nominal bitrate. Using this and the file size should give a reasonably good guess at the actual duration. How accurate does it have to be? > > A far easier method is to query the file that you've just > > uploaded. Is there any reason why you can't just pass this to > > taglib? > I've not found any way to get hold of a file produced by FUSE > from within a FUSE client; i.e., I don know how to reference it > or just set its pathname! One alternative would be to produce a > dummy temporary file just with a header and trailer large enough > to be sure they hold the tag info. > > With the USB interface this could be easyer if we could somehow > determine the /mnt/karma2/fid0/??0 name (from within lkarmafs). > This might require a low-level libkarma call, however. There's no way of finding the source file. That would be impossible since FUSE doesn't know itself. It is just handed chunks of data by "cp" or whatever application is doing the copying. No, I meant the file that is being written *to*. We know that because we are the ones doing the writing! libkarma may not have an interface for this currently, but it would be pretty trivial to add. Only works for USB, of course. Keith. ------------------------------------------------------------------------- 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
