2006-07-29: Keith Bennett dixit: > On Sat, Jul 29, 2006, EV wrote: > > 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.
As I said, we don't need to copy the whole file, just header and trailer chunks of say 20KB or so (id3v2 or vorbis may have large tag areas) > > 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. Mp3s may have only trailer tag areas (no header tags). > 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. Agree. /tmp/ can be used as a back-off method. We can go this direction already. 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). > 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? I've tested tunes with 1 or 2 seconds off and the RK seems to be happy. We need more experimentation to find the limits. > > > 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. > > [...] 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. > libkarma may not have an interface for this currently, but it > would be pretty trivial to add. Only works for USB, of course. 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. Best, 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
