Difference between revisions of "MetaData Handling"
Langstonius (Talk | contribs) |
Langstonius (Talk | contribs) (→Meta-Data Handling) |
||
| Line 1: | Line 1: | ||
[[Category:Programmer's Guide]] | [[Category:Programmer's Guide]] | ||
| − | + | =Meta-Data Handling= | |
| + | |||
| + | ==Basic Handling Overview== | ||
| + | ANY attribute stored in the media database for a file be it audio, video or otherwise gets stored on a file level as well. How it gets stored, depends on the file: | ||
| + | |||
| + | '''mp3''' files: Embed ALL the data into the ID3 section of the mp3 file. For any attributes that match analogously we use those attribute types for anything THAT DOESN'T we store it in a format that's read by SerializeClass, in a GEOB tag inside the ID3 section of the file. | ||
| + | |||
| + | '''Ogg and Flac''' files, we do similar, using Taglib to map attributes analogously into those media metadata types. TagLib does not support storing blobs, so it can't store everything into the ogg and flac files. Pictures, are stored, as APIC sections in MP3 files | ||
| + | or as picture resources in ogg files. Flac files do not have this facility. | ||
| + | |||
| + | '''FOR ANYTHING ELSE''' | ||
| + | We create what is essentially a file that just contains an ID3 section so it looks like an empty mp3 file alongside the existing file | ||
| + | which stores the attributes and data in exactly the same way as mp3 files using APIC resources to store pictures, mapping common attributes to id3 attributes and anything else as a SerializeClass blob inside a GEOB section. | ||
| + | |||
| + | '''In Practice''' | ||
| + | When a new file is detected by UpdateMedia, its data is interrogated, depending on whether there is an ID3 file, or an embedded id3 section, or something that taglib can handle and the data is brought back into the database. If there is a GEOB section then the other attributes not directly analogous will be brought back in. | ||
| + | |||
| + | When the pictures are brought in, a new picture row is made in the picture table, and the appropriate attribute and join tables. | ||
| + | and the picture is stored in '/home/mediapics/xxxxx.jpg' where 'xxxxx' is the PK_Picture row. If tags change on the linuxmce side, they're supposed to be reincorporated back into the serialized tag form. The URL to an image resource if one was specified, is stored as well. | ||
| + | |||
| + | As per Tschak from IRC 7 sept 2010 | ||
| + | --[[User:Langstonius|Langstonius]] 05:48, 8 September 2010 (CEST) | ||
Revision as of 05:48, 8 September 2010
Meta-Data Handling
Basic Handling Overview
ANY attribute stored in the media database for a file be it audio, video or otherwise gets stored on a file level as well. How it gets stored, depends on the file:
mp3 files: Embed ALL the data into the ID3 section of the mp3 file. For any attributes that match analogously we use those attribute types for anything THAT DOESN'T we store it in a format that's read by SerializeClass, in a GEOB tag inside the ID3 section of the file.
Ogg and Flac files, we do similar, using Taglib to map attributes analogously into those media metadata types. TagLib does not support storing blobs, so it can't store everything into the ogg and flac files. Pictures, are stored, as APIC sections in MP3 files or as picture resources in ogg files. Flac files do not have this facility.
FOR ANYTHING ELSE We create what is essentially a file that just contains an ID3 section so it looks like an empty mp3 file alongside the existing file which stores the attributes and data in exactly the same way as mp3 files using APIC resources to store pictures, mapping common attributes to id3 attributes and anything else as a SerializeClass blob inside a GEOB section.
In Practice When a new file is detected by UpdateMedia, its data is interrogated, depending on whether there is an ID3 file, or an embedded id3 section, or something that taglib can handle and the data is brought back into the database. If there is a GEOB section then the other attributes not directly analogous will be brought back in.
When the pictures are brought in, a new picture row is made in the picture table, and the appropriate attribute and join tables. and the picture is stored in '/home/mediapics/xxxxx.jpg' where 'xxxxx' is the PK_Picture row. If tags change on the linuxmce side, they're supposed to be reincorporated back into the serialized tag form. The URL to an image resource if one was specified, is stored as well.
As per Tschak from IRC 7 sept 2010 --Langstonius 05:48, 8 September 2010 (CEST)
