On Sun, Jul 30, 2006, Keith Bennett wrote: > On Sat, Jul 29, 2006, EV wrote: > > > I thought the rid was used for synchronization. Remember there > > > was some marketing stuff that said that RMM would not copy > > > dupes even if they had different tags; I always figured this > > > was done by comparing the rids (md5s of parts of the audio > > > data). > > > > This seems correct. But not libkarma/riocp or lkarmafs care > > about rid's or dupes... And I think the same is true for rmml. > > Do you think we should address this issue? > > > > As with the duration property, this would be troublesome for > > lkarmafs... > > This sounds pretty cool and should definitely be implemented.
Unfortunately, this is all a bit more tricky than I first thought. The actual duplicate rid implementation is trivial. The problem comes with generating the rid using only the audio data. In order to achieve this you have to know how big the headers are and where they are located. This is where my knowledge of audio file tagging lets me down. Here is what I *think* I know: As far as I can tell, both ID3v1 and ID3v2 tags can be used on mp3, flac and vorbis files but cannot be used on wav files. Is this correct? vorbis files are always encapsulated within an ogg bitstream. Flac can optionally be encapsulated within an obb bitstream. vorbis and Flac both use the vorbis comment format. The easiest method for getting past the tags at the beginning of a vorbis file is to just look for the first occurrence of "\x05vorbis". This will work even if id3 tags are used. There is still the possibility of an id3 tag at the end of the file. I guess that these are easy enough to search for using the last 8k or so of data. Flac needs a bit more work because there is no marker at the end of the header. Instead you must find the first metablock marker and read through the list. This is pretty easy, though. If the flac file is encapsulated in an ogg bitstream, then all the header data is contained in the second page so it is only necessary to find the length of that. Does this info all sound correct? I would also like to detect the file type based on its contents rather than its suffix. If we are reading the header anyway then this should come for free. I think that the above info covers all possible scenarios for ogg and flac files. I don't know anything about mp3s. Does mp3.c contain sufficient functionality for detecting an MP3 file? I also don't know anything about wav headers. (There's an awful lot of things that I don't know to be honest!) All the wavs on my system start with "RIFF4;..WAVEfmt" but I'm guessing that this isn't the only possibility. Does anyone here have more of a clue than me? 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
