Any interest in adding MP3 ID3v2 read/write capability to Koha?
Hi, We have a good sized collection (and growing) of MP3 encoded audio that we plan to use Koha to catalog. Most of our MP3's have to have tags created and added to them. A few have tags already. The job of creating them could be made a lot easier by adding the ability to write ID3v2 tags to the MP3's based on the corresponding marc record for the audio archive. (Our in-house software does this currently, but is coded in VB rather than Perl.) We have been looking at using MP3::Tag to incorporate this read/write capability into Koha. To do this right, I think some discussion is in order prior to beginning. I'd like to hear feedback on two points: 1. From the user prospective: Is there any interest/demand for this type of feature? 2. From the developer prospective: What is the best mapping plan for marc fields to ID3v2 frames and vise-versa? If you are not familiar with the ID3v2 standard, take a look at http://www.id3.org/id3v2.4.0-frames which is probably the relevant part for this discussion. Regards, Chris -- Chris Nighswonger Faculty Member Network & Systems Director Foundations Bible College & Seminary www.foundations.edu www.fbcradio.org
"Chris Nighswonger" <cnighswonger@foundations.edu> wrote:
We have been looking at using MP3::Tag to incorporate this read/write capability into Koha. To do this right, I think some discussion is in order prior to beginning. I'd like to hear feedback on two points:
1. From the user prospective: Is there any interest/demand for this type of feature?
2. From the developer prospective: What is the best mapping plan for marc fields to ID3v2 frames and vise-versa?
I'm not sure about the mapping plan (I'm not very MARC) but I think there is user interest in this feature. Would it be better to use Audio::TagLib for a more general multi-format audio file tagging? If you could leave the door open to Image::ExifTool for many graphics formats in a similar system, that would be absolutely fantastic! One moon on a stick to go, please! ;-) -- MJ Ray http://mjr.towers.org.uk/email.html tel:+44-844-4437-237 - Webmaster-developer, statistician, sysadmin, online shop builder, consumer and workers co-operative member http://www.ttllp.co.uk/ - Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/
On 11/30/07, MJ Ray <mjr@phonecoop.coop> wrote:
"Chris Nighswonger" <cnighswonger@foundations.edu> wrote: Would it be better to use Audio::TagLib for a more general multi-format audio file tagging?
++ If you could leave the door open to
Image::ExifTool for many graphics formats in a similar system, that would be absolutely fantastic!
Tnx for the heads-up. I missed these two modules completely. Too bad Image::ExifTool does not support more audio file types. It could be an all-in-one solution. I would think that once the basic structure is in place, supporting read/write of any filetype header would be relatively easy. -- Chris Nighswonger Faculty Member Network & Systems Director Foundations Bible College & Seminary www.foundations.edu www.fbcradio.org
"Chris Nighswonger" <cnighswonger@foundations.edu> wrote:
Tnx for the heads-up. I missed these two modules completely. Too bad Image::ExifTool does not support more audio file types. It could be an all-in-one solution.
It may be possible to extend Image::ExifTool to support writing tags for more file types, but there might be some reason why it hasn't been done and I don't know how much work you're prepared to do. Also, audio and images are different, so may need mapping differently anyway. Glad it helped, -- MJ Ray http://mjr.towers.org.uk/email.html tel:+44-844-4437-237 - Webmaster-developer, statistician, sysadmin, online shop builder, consumer and workers co-operative member http://www.ttllp.co.uk/ - Writing on koha, debian, sat TV, Kewstoke http://mjr.towers.org.uk/
Hi, On 11/30/07, Chris Nighswonger <cnighswonger@foundations.edu> wrote:
1. From the user prospective: Is there any interest/demand for this type of feature?
I can confirm that there is a lot of interest in this sort of thing for digital library projects. See http://meta-extractor.sourceforge.net/ for a (Java) tool built by the National Library of New Zealand.
2. From the developer prospective: What is the best mapping plan for marc fields to ID3v2 frames and vise-versa? If you are not familiar with the ID3v2 standard, take a look at http://www.id3.org/id3v2.4.0-frames which is probably the relevant part for this discussion.
Doing a mapping to MARC is where it would get tricky -- most digital library projects stuff this sort of data into XML following various schemas. One approach might be to look for example mappings to Dublin Core entities, then map back to MARC, e.g., dc.title = 245$a, etc. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
On 11/30/07, Galen Charlton <galen.charlton@liblime.com> wrote:
Hi,
On 11/30/07, Chris Nighswonger <cnighswonger@foundations.edu> wrote:
1. From the user prospective: Is there any interest/demand for this type of feature?
I can confirm that there is a lot of interest in this sort of thing for digital library projects. See http://meta-extractor.sourceforge.net/ for a (Java) tool built by the National Library of New Zealand.
2. From the developer prospective: What is the best mapping plan for marc fields to ID3v2 frames and vise-versa? If you are not familiar with the ID3v2 standard, take a look at http://www.id3.org/id3v2.4.0-frames which is probably the relevant part for this discussion.
Doing a mapping to MARC is where it would get tricky -- most digital library projects stuff this sort of data into XML following various schemas. One approach might be to look for example mappings to Dublin Core entities, then map back to MARC, e.g., dc.title = 245$a, etc. Or perhaps it's 'bout time' we take advantage of Zebra's ability to index multiple formats and create a set of Dublin Core frameworks? :-)
Cheers, -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
On 12/2/07, Joshua Ferraro <joshua.ferraro@liblime.com> wrote:
Doing a mapping to MARC is where it would get tricky -- most digital library projects stuff this sort of data into XML following various schemas. One approach might be to look for example mappings to Dublin Core entities, then map back to MARC, e.g., dc.title = 245$a, etc. Or perhaps it's 'bout time' we take advantage of Zebra's ability to index multiple formats and create a set of Dublin Core frameworks? :-)
Whew! Just took a look at www.dublincore.org and it looks like I need a Dublincore-101 course or the short version or something. :-) So explain a bit more. I was thinking of a "simple" mapping from MARC to id3v2 frames. Are you suggesting MARC to DC to id3v2? And how does Zebra fit in here? (Sorry if these are simple questions?) -- Chris Nighswonger Faculty Member Network & Systems Director Foundations Bible College & Seminary www.foundations.edu www.fbcradio.org
Hi, On 12/3/07, Chris Nighswonger <cnighswonger@foundations.edu> wrote:
On 12/2/07, Joshua Ferraro <joshua.ferraro@liblime.com> wrote:
Or perhaps it's 'bout time' we take advantage of Zebra's ability to index multiple formats and create a set of Dublin Core frameworks? :-)
Whew! Just took a look at www.dublincore.org and it looks like I need a Dublincore-101 course or the short version or something. :-)
FWIW, Dublin Core started out *as* the short version. :) If you ignore most of the cruft, http://www.dublincore.org/documents/dcmi-terms/ has the gist of it -- DC is just a relatively small set of elements for a metadata record describing a resource.
So explain a bit more. I was thinking of a "simple" mapping from MARC to id3v2 frames. Are you suggesting MARC to DC to id3v2? And how does Zebra fit in here? (Sorry if these are simple questions?)
More like a mapping from id3v2 to DC, like one found at http://age.hobba.nl/audio/tag_frame_reference.html. I'm not vouching for that specific mapping, by the way, but it is an example. Once you map from id3v2, you can express DC as XML, then have Zebra index the DC natively. Throw in some XSLT to display the DC in the OPAC, and you can search and display this metadata without necessarily having to map to MARC. But if you want something to play with now, you can map your DC to MARC per LC's crosswalk (http://www.loc.gov/marc/marc2dc.html) and generate MARC records to load into Koha. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709
On 12/3/07, Galen Charlton <galen.charlton@liblime.com> wrote:
So explain a bit more. I was thinking of a "simple" mapping from MARC to id3v2 frames. Are you suggesting MARC to DC to id3v2? And how does Zebra fit in here? (Sorry if these are simple questions?)
More like a mapping from id3v2 to DC, like one found at http://age.hobba.nl/audio/tag_frame_reference.html. I'm not vouching for that specific mapping, by the way, but it is an example.
Once you map from id3v2, you can express DC as XML, then have Zebra index the DC natively. Throw in some XSLT to display the DC in the OPAC, and you can search and display this metadata without necessarily having to map to MARC. But if you want something to play with now, you can map your DC to MARC per LC's crosswalk (http://www.loc.gov/marc/marc2dc.html) and generate MARC records to load into Koha.
Are we suggesting that there is really no need to take id3v2 data and map it to marc records? If so (and I'm not sure this is what we are saying), how will biblio entries for these resources be added? I would like to be able: a. to simply point the staff client to an mp3 and have it generate a marc record from the id3v2 header info, give me the opportunity to review it for completeness (given that not all mp3's have pertinent data), and insert it into the catalog. And... b. when an mp3 arrives which has no id3v2 header or an incomplete one, enter the appropriate marc record (manually or from loc, etc.), and then generate/write an id3v2 header based on that data to the mp3. Both id3v2 and marc21 appear quite a bit more atomic than dc. It would seem to be adding extra work to crosswalk to dc. I may be lacking in my understanding here, so feel free to correct me. Chris -- Chris Nighswonger Faculty Member Network & Systems Director Foundations Bible College & Seminary www.foundations.edu www.fbcradio.org
participants (4)
-
Chris Nighswonger -
Galen Charlton -
Joshua Ferraro -
MJ Ray