windowshade Wrote: > Thanks, gerph for your input and for your precise use of language. In > the sample file, ARTIST appears to be null-delimited just like GENRE. > There are no duplicate frames. > > TPE1... Yo-Yo Ma\0Bobby McFerrin\0... > TCON... Classical\0Experimental\0... > > I'll solicit some opinions from the foobar2000 forum regarding > compliance with the ID3v2.4 informal standard prior to submitting an > enhancement request.
Ok, I've had a look at this and after a bit of messing around I've got a patch that I've tested OUTSIDE of slimserver only. I've tested it in a number of forms with my own tests and your example and it appears to work correctly for what I have determined is 'correctly'. I am concerned, however, that there is a possibility that this will now introduce multiple ARTIST values as an array. That is, the ARTIST value in the hash changes from being a scalar to being an array reference when the file contains multiple artists (either because the ID3v1.1 differs from the ID3v2, or because there are multiple entries in the ID3v2 field). This may cause problems for some clients. Indeed, I'm not sure that having the IDv3.1 and the ID3v2 exist concurrently is at all a good idea (fortunately, this doesn't happen with the current versions of SlimServer). The patch applies the change to the behaviour of all the T??? frames in ID3v2 files. It doesn't actually pay attention to the fact that this is ID3v2.4 only in the parsing function - partly because that's the way that the code was before I looked at it and partly because I've seen people put ID3v2.4 frames into ID3v2.3 files (sigh) and thus we probably ought to treat them similarly. All such frames can become arrays if they have multiple fields within them. The only exceptions to this are TCON, which is handled separately because of the numeric genres that may be present (unchanged code), and TXXX which is allowed to occur multiple times and has slightly different rules. In the form which slimserver uses the call, getmp3tag(2, undef, 0), this means that the key 'ARTIST' (or 'ALBUM', or any of the others) may now be an arrayref or a scalar. Prior to this patch, only 'GENRE' could be an arrayref or scalar - all the others being only scalars. I have NOT tested this live on slimserver. Not because I'm lazy, but because the HD on my server is failing and I'm in the process of backing up which kinda takes priority. Whilst I've been waiting for the backups, though, I've been able to test this code in standalone form on another box. Somebody will need to have a look at it and see if it does work in a live slimserver system, and whether - if it does not - other changes are necessary. I'll be able to look at it properly myself in the middle of next week, I think. Sorry. Hopefully I'll still be around to fix things if I can see them in a standalone use. +-------------------------------------------------------------------+ |Filename: Info-multi-text-field-values.diff | |Download: http://forums.slimdevices.com/attachment.php?attachmentid=1585| +-------------------------------------------------------------------+ -- gerph ------------------------------------------------------------------------ gerph's Profile: http://forums.slimdevices.com/member.php?userid=1819 View this thread: http://forums.slimdevices.com/showthread.php?t=26483 _______________________________________________ beta mailing list [email protected] http://lists.slimdevices.com/lists/listinfo/beta
