[mythtv] MythMusic metadata read/write rewrite... stumbling block....

[Colin Guthrie]

Hi,

This is mainly for Thor or any other interested party.

I've attached a patch, but it's only really for the sake of looking as 
it's still got a few problems.

I've hit a kind of major stumbling block in the writing of ID3 tags.

To recap, my intension was to use MAD's libid3tag to write the ID3v2 
tags onto newly encoded files and also to eventually allow MythMusic to 
alter the Tags in the files as the Metadata changes in the database.

Now, I've got WMA (read only) working, Vorbis Comments in a Ogg stream 
seem to work perfect. Vorbis Comments in a FLAC stream seem to be a 
little odd in that they work fine on first write and then the file just 
grows there after. I've not really looked at this code tho' as it's more 
or less a verbatim copy from how it is just now which was presumable 
written with a single write in mind.

Anyways, I had some test files and everything was cool, reading/writing 
ID3s happily. Then I tried it with a Myth ripped, Lame encoded file and 
the update refused to happen while saying all the time that everything 
was fine.

Well, I eventually tracked down the problem. I quote from 
libid3tag-0.15.1b/file.c:
<quote>
   /* hard general case: rewrite entire file */

   /* ... */

  done:
   return 0;
</quote>

Basically, libid3tag (part of MAD) will only update the id3v2 tag if the 
tag size doesn't change. Moreover, it has no feedback mechanism to 
determin if this has happened, so you just don't know if it's worked or 
not. This I would describe as a royal pain in the you-know-what!!


So, I figured, I could live with this provided that it could at least 
write the tags properly to Myth encoded files, so all I have to do is 
make sure the LAME inserts a suitibly sized ID3 tag to allow us to 
overwrite it. Trouble is I'm not sure how LAME does it's calculations 
for the header, but I just cannot get it to tally.

Here is what I did: I hacked the LAME encoding in Myth to only write a 
single field to the ID3 tag (title). Looking in hexedit at the resulting 
file, my ID3 header size was quite small. I used a command line utility 
(id3v2) to add an artist field. The TAGs header bytes changed to a much 
larger value. Adding an Album field caused more data to be written to 
the tag, but interestingly the header size did not change. So I can only 
presume that the command line utility (id3v2) analysed the file to 
extend the header to the maximum size it has available (LAME did seem to 
leave some space after the ID3v2 Tag which is handy).

So, if LAME wrote it's header size correctly, then I could more or less 
use libid3tag fairly successfully. I could probably code a work around 
for the case when it fails too, by detecting if the new tag info will go 
beyond the space available and writing a simple tool to extend the space 
available. The more robust solution would be to patch libid3tag to cope, 
which I don't think would be all that hard really.

However, even if I do patch libid3tag, I need a shorter term workaround 
as it'll take a while for my id3tag patch to filter through to real 
environments. So I really need to get LAME writing it's header size 
correctly. Should I just post process the LAME file and write the header 
size correctly? THis shoudl be relativly simple.

Perhaps someone with more experience of ID3 tags or LAME could advise?

Cheers

Col.



-- 

+------------------------+
|     Colin Guthrie      |
+------------------------+
|   myth at colin.guthr.ie  |
| http://colin.guthr.ie/ |
+------------------------+
-------------- next part --------------
A non-text attachment was scrubbed...
Name: metadata.diff.bz2
Type: application/x-bzip2
Size: 16970 bytes
Desc: not available
Url : http://mythtv.org/pipermail/mythtv-dev/attachments/20041021/018863cb/metadata.diff.bin