PDA

View Full Version : Slimserver feature request -- additional 'browse by"capabilities



Eric Marcoullier
2003-12-26, 10:02
I was tempted to integrate this myself, but then
looked at the code and realized how rusty my perl is.
As a result, I'm posting this on the list in the hopes
of sparking a discussion and getting someone else
motivated to impliment it :)

I have always been disappointed that ID3 tags only
support a single genre. While music can be broadly
grouped into Rock, Jazz, Country, etc, I usually want
to listen to all my punk rock music or west coast jazz
or ska. Unfortunately, most types of music fall into
multiple categories, so I am forced to choose either a
very broad genre or inaccurately choose a single
sub-genre.

As a result, I have been going with Allmusic's
approach of keeping the genre very broad, but then
subclassifying each CD by "styles" and putting those
styles in the comments field in a comma delimited
format.

With the slimserver, you can currently browse by
Genre, Artist and Album. I suggest adding one more
search, by Comments, that uses the comments field as a
simple database for styles, ratings, performers, or
whatever. In my case, this would enable me to browse
by a narrower granularity than Genre and have all the
relevant tracks show up.

Thoughts?

Cheers!
Eric

rpgoldman@real-time.com
2003-12-27, 13:09
>>>>> "Eric" == Eric Marcoullier <bpm140 (AT) yahoo (DOT) com> writes:

Eric> I was tempted to integrate this myself, but then
Eric> looked at the code and realized how rusty my perl is.
Eric> As a result, I'm posting this on the list in the hopes
Eric> of sparking a discussion and getting someone else
Eric> motivated to impliment it :)

Eric> I have always been disappointed that ID3 tags only
Eric> support a single genre. While music can be broadly
Eric> grouped into Rock, Jazz, Country, etc, I usually want
Eric> to listen to all my punk rock music or west coast jazz
Eric> or ska. Unfortunately, most types of music fall into
Eric> multiple categories, so I am forced to choose either a
Eric> very broad genre or inaccurately choose a single
Eric> sub-genre.

Eric> As a result, I have been going with Allmusic's
Eric> approach of keeping the genre very broad, but then
Eric> subclassifying each CD by "styles" and putting those
Eric> styles in the comments field in a comma delimited
Eric> format.

Eric> With the slimserver, you can currently browse by
Eric> Genre, Artist and Album. I suggest adding one more
Eric> search, by Comments, that uses the comments field as a
Eric> simple database for styles, ratings, performers, or
Eric> whatever. In my case, this would enable me to browse
Eric> by a narrower granularity than Genre and have all the
Eric> relevant tracks show up.

At the expense of possibly being overambitious, I'd say that adding a
special ID3v2 frame for a better genre structure would be the way to
go. Hijacking the comment field seems suboptimal (but, of course,
requires less id3v2 tag hackery). The current genres are very crude
and, as you point out, have no internal structure (e.g., Opera ISA
Classical should be true...).

r

dean
2003-12-27, 14:33
According to the ID3 spec, you can put multiple artists in the artist
tag, separated by slashes to indicate multiple people.
What do folks think of making this work for genres as well?

-dean

On Dec 27, 2003, at 12:09 PM, rpgoldman (AT) real-time (DOT) com wrote:

>>>>>> "Eric" == Eric Marcoullier <bpm140 (AT) yahoo (DOT) com> writes:
>
> Eric> I was tempted to integrate this myself, but then
> Eric> looked at the code and realized how rusty my perl is.
> Eric> As a result, I'm posting this on the list in the hopes
> Eric> of sparking a discussion and getting someone else
> Eric> motivated to impliment it :)
>
> Eric> I have always been disappointed that ID3 tags only
> Eric> support a single genre. While music can be broadly
> Eric> grouped into Rock, Jazz, Country, etc, I usually want
> Eric> to listen to all my punk rock music or west coast jazz
> Eric> or ska. Unfortunately, most types of music fall into
> Eric> multiple categories, so I am forced to choose either a
> Eric> very broad genre or inaccurately choose a single
> Eric> sub-genre.
>
> Eric> As a result, I have been going with Allmusic's
> Eric> approach of keeping the genre very broad, but then
> Eric> subclassifying each CD by "styles" and putting those
> Eric> styles in the comments field in a comma delimited
> Eric> format.
>
> Eric> With the slimserver, you can currently browse by
> Eric> Genre, Artist and Album. I suggest adding one more
> Eric> search, by Comments, that uses the comments field as a
> Eric> simple database for styles, ratings, performers, or
> Eric> whatever. In my case, this would enable me to browse
> Eric> by a narrower granularity than Genre and have all the
> Eric> relevant tracks show up.
>
> At the expense of possibly being overambitious, I'd say that adding a
> special ID3v2 frame for a better genre structure would be the way to
> go. Hijacking the comment field seems suboptimal (but, of course,
> requires less id3v2 tag hackery). The current genres are very crude
> and, as you point out, have no internal structure (e.g., Opera ISA
> Classical should be true...).
>
> r
>

Scott Haug
2003-12-27, 15:08
Saturday, December 27, 2003, 1:33:22 PM, you wrote:

db> According to the ID3 spec, you can put multiple artists in the artist
db> tag, separated by slashes to indicate multiple people.
db> What do folks think of making this work for genres as well?

According to the ID3v2.3 spec, multiple genres are supported when
using ID3v1.1-style when using the TCON tag. The genres are referenced
by their numeric value, and are surrounded by parentheses:

"(21)(39)"

This would be interpreted as "Ska" with a "Noise" subgenre refinement.

http://www.id3.org/id3v2.3.0.html#TCON

If the tag uses ID3v2.4, then multiple strings are available in all
T*** tags, as they're separated by null-terminators appropriate for
the encoding.

"21" $00 "Eurodisco" $00

http://www.id3.org/id3v2.4.0-frames.txt (search for TCON)

The only thing not supported directly are multiple free-form genres in
ID3v2.3 tags. I haven't followed the id3v2 mailing lists in some time,
so I don't know if there are other accepted workarounds for this. But
I think the slimserver should support multiple genres as specified,
and then make '/' separation for ID3v2.3 tags an optional server
setting, since this isn't supported by the spec.

-Scott

dean
2003-12-27, 19:32
Great info. I've added your notes to the bug report.

-dean

On Dec 27, 2003, at 2:08 PM, Scott Haug wrote:

> Saturday, December 27, 2003, 1:33:22 PM, you wrote:
>
> db> According to the ID3 spec, you can put multiple artists in the
> artist
> db> tag, separated by slashes to indicate multiple people.
> db> What do folks think of making this work for genres as well?
>
> According to the ID3v2.3 spec, multiple genres are supported when
> using ID3v1.1-style when using the TCON tag. The genres are referenced
> by their numeric value, and are surrounded by parentheses:
>
> "(21)(39)"
>
> This would be interpreted as "Ska" with a "Noise" subgenre refinement.
>
> http://www.id3.org/id3v2.3.0.html#TCON
>
> If the tag uses ID3v2.4, then multiple strings are available in all
> T*** tags, as they're separated by null-terminators appropriate for
> the encoding.
>
> "21" $00 "Eurodisco" $00
>
> http://www.id3.org/id3v2.4.0-frames.txt (search for TCON)
>
> The only thing not supported directly are multiple free-form genres in
> ID3v2.3 tags. I haven't followed the id3v2 mailing lists in some time,
> so I don't know if there are other accepted workarounds for this. But
> I think the slimserver should support multiple genres as specified,
> and then make '/' separation for ID3v2.3 tags an optional server
> setting, since this isn't supported by the spec.
>
> -Scott
>
>

rpgoldman@real-time.com
2003-12-27, 19:46
>>>>> "dean" == dean blackketter <dean (AT) slimdevices (DOT) com> writes:

dean> According to the ID3 spec, you can put multiple artists in the artist
dean> tag, separated by slashes to indicate multiple people.
dean> What do folks think of making this work for genres as well?

That sounds great! I was just reading that in the ID3v2.4 spec, and
it sounded like the right way to handle the problem. The spec also
seems to deprecate the use of the numerical genre ids, correctly
arguing that they get out of synch and out of date.

BTW, does the slimserver do ok with multiple artists in a single tag?

Thanks,
R

rpgoldman@real-time.com
2003-12-27, 19:49
>>>>> "Scott" == Scott Haug <slimp3-users (AT) houseofhaug (DOT) net> writes:

Scott> Saturday, December 27, 2003, 1:33:22 PM, you wrote:
db> According to the ID3 spec, you can put multiple artists in the artist
db> tag, separated by slashes to indicate multiple people.
db> What do folks think of making this work for genres as well?

[...snip...]

Scott> The only thing not supported directly are multiple
Scott> free-form genres in ID3v2.3 tags. I haven't followed the
Scott> id3v2 mailing lists in some time, so I don't know if there
Scott> are other accepted workarounds for this. But I think the
Scott> slimserver should support multiple genres as specified, and
Scott> then make '/' separation for ID3v2.3 tags an optional
Scott> server setting, since this isn't supported by the spec.

Yes, I was confused by the '/' remark, too. Seemed like the default
separator would have been null bytes.

I'd love it if Slimserver would support the intermediate level TIT1
between the album title and track title, too! If I get a chance, I'll
try to look at the code and see how to do it.

Of course, I'll have to find a tagger that will put the dratted things
on....

R

Scott Haug
2003-12-27, 22:53
Saturday, December 27, 2003, 6:49:08 PM, rpgoldman wrote:

rrtc> Yes, I was confused by the '/' remark, too. Seemed like the default
rrtc> separator would have been null bytes.

[snip]

rrtc> Of course, I'll have to find a tagger that will put the dratted things
rrtc> on....

I think using a visible, enterable character (or characters) as a
separator would be easier to manage than the null character. For one,
the id3v2.3 spec clearly states that anything following the null
character in a frame should be ignored. But more importantly, it will
be far easier to enter these types of genres in existing tag editors.
Many tag editors that support id3v2.3 tags allow for arbitrary genres,
so it would be easy for an end user to orgnaize their music collection
with genres like "Folk/Acoustic/Singer-songwriter". Such a thing would
be far more difficult, if not impossible, if null bytes were used as a
separator.

That said, when parsing id3v2.4 tags, I think the null byte separator
should be honored (per the 2.4 spec) and the "extended" separator used
for 2.3 tags be ignored. Finding a editor that allows for entering
such type of genres for id3v2.4 tags is another matter...

-Scott

ron 'coyote' lussier
2003-12-28, 10:31
On Dec 27, 2003, at 1:33 PM, dean blackketter wrote:

> According to the ID3 spec, you can put multiple artists in the artist
> tag, separated by slashes to indicate multiple people.
> What do folks think of making this work for genres as well?

I think it would be fantastic. Especially if you convinced the iTunes
people to support it as well! (iTunes 5 is just around the corner,
ain't it?)

--- , /),
(( -.((_)) _,) Joyous Solstice!
,\`.' `-','
`.> (,-
,', `._,)
ron lussier / lenscraft (( ) (`--' fine art
photography
67 crescent avenue `'( ) _ _,-.\
sausalito / ca 94965 /,' \( ) `'
http://lenscraft.com/
(( `\
`

rpgoldman@real-time.com
2003-12-28, 13:58
>>>>> "Scott" == Scott Haug <scott (AT) houseofhaug (DOT) net> writes:

Scott> Saturday, December 27, 2003, 6:49:08 PM, rpgoldman wrote:
rrtc> Yes, I was confused by the '/' remark, too. Seemed like the default
rrtc> separator would have been null bytes.

Scott> [snip]

rrtc> Of course, I'll have to find a tagger that will put the dratted things
rrtc> on....

Scott> I think using a visible, enterable character (or
Scott> characters) as a separator would be easier to manage than
Scott> the null character. For one, the id3v2.3 spec clearly
Scott> states that anything following the null character in a
Scott> frame should be ignored. But more importantly, it will be
Scott> far easier to enter these types of genres in existing tag
Scott> editors. Many tag editors that support id3v2.3 tags allow
Scott> for arbitrary genres, so it would be easy for an end user
Scott> to orgnaize their music collection with genres like
Scott> "Folk/Acoustic/Singer-songwriter". Such a thing would be
Scott> far more difficult, if not impossible, if null bytes were
Scott> used as a separator.

Scott> That said, when parsing id3v2.4 tags, I think the null byte
Scott> separator should be honored (per the 2.4 spec) and the
Scott> "extended" separator used for 2.3 tags be ignored. Finding
Scott> a editor that allows for entering such type of genres for
Scott> id3v2.4 tags is another matter...

Seems like you understand the standard better than I do. IIUC, the
standard calls for us to mark the character encoding with a two byte
code number, and then the encoding somehow dictates what the
"termination code"/null byte is. Do you know how we can determine
what the termination code is? Presumably it should be possible to
choose something printable for the benefit of existing editors, yes?

Cheers,
R

Scott Haug
2003-12-28, 15:27
Sunday, December 28, 2003, 12:58:36 PM, rpgoldman wrote:

rrtc> Seems like you understand the standard better than I do. IIUC, the
rrtc> standard calls for us to mark the character encoding with a two byte
rrtc> code number, and then the encoding somehow dictates what the
rrtc> "termination code"/null byte is. Do you know how we can determine
rrtc> what the termination code is? Presumably it should be possible to
rrtc> choose something printable for the benefit of existing editors, yes?

There was a time (long since passed, thankfully) when I spent far more
time pouring over the ID3v2 spec(s) than was healthy...

ID3v2.3 supports two encoding types: ISO-8859-1 (ASCII) and UCS-2
(16-bit Unicode). The encoding is specified in appropriate frames with
a single byte.

From http://www.id3.org/id3v2.3.0.html#sec3.3

Frames that allow different types of text encoding have a text
encoding description byte directly after the frame size. If
ISO-8859-1 is used this byte should be $00, if Unicode is used it
should be $01.

From http://www.id3.org/id3v2.3.0.html#sec4.2

If the textstring is followed by a termination ($00 (00)) all the
following information should be ignored and not be displayed.

So, if the frame uses ASCII, the termination will be a single-byte
null character ($00); for Unicode, two null bytes ($00 $00).

I don't know of any editor, other than hex editors, that lets you
enter a null byte into a text string, at least not without causing
undetermined behavior in the editor. Thus, for ID3v2.3 tags, if we
want to have some sort of slimserver-specific interpretation of
multiple free-form (that is, non-ID3v1-style) genres for a file, then
it's best we choose a printable character as a separator. Since
several other ID3v2.3 frames use "/" as a separator between entries
(TCOM, TEXT, TOLY, TOPE, TPE1, TPOS, TRCK), then it seems like an easy
extension to support this in TCON as well. Again, I would make this a
server setting, and only do this for ID3v2.3 tags.

Also, in another email in this thread, you mentioned that the ID3v2.4
spec deprecates the use of numerical genre id's. This isn't entirely
accurate. Both ID3v2.3 and ID3v2.4 fully support the ID3v1-style
numerical genres (specified as numeric strings, rather than a single
byte as in ID3v1). They both allow for specifying one or more such
numerical genres, intermixed with one (for ID3v2.3) or more (for
ID3v2.4) plain-text genres.

-Scott

rpgoldman@real-time.com
2003-12-29, 07:48
>>>>> "Scott" == Scott Haug <scott (AT) houseofhaug (DOT) net> writes:

Scott> Sunday, December 28, 2003, 12:58:36 PM, rpgoldman wrote:
rrtc> Seems like you understand the standard better than I do. IIUC, the
rrtc> standard calls for us to mark the character encoding with a two byte
rrtc> code number, and then the encoding somehow dictates what the
rrtc> "termination code"/null byte is. Do you know how we can determine
rrtc> what the termination code is? Presumably it should be possible to
rrtc> choose something printable for the benefit of existing editors, yes?

Scott> There was a time (long since passed, thankfully) when I
Scott> spent far more time pouring over the ID3v2 spec(s) than was
Scott> healthy...

Scott> ID3v2.3 supports two encoding types: ISO-8859-1 (ASCII) and UCS-2
Scott> (16-bit Unicode). The encoding is specified in appropriate frames with
Scott> a single byte.

>> From http://www.id3.org/id3v2.3.0.html#sec3.3

Scott> Frames that allow different types of text encoding have a text
Scott> encoding description byte directly after the frame size. If
Scott> ISO-8859-1 is used this byte should be $00, if Unicode is used it
Scott> should be $01.

>> From http://www.id3.org/id3v2.3.0.html#sec4.2

Scott> If the textstring is followed by a termination ($00 (00))
Scott> all the following information should be ignored and not
Scott> be displayed.

OK, so if I understand this correctly, it means that in the 2.3.0
version of ID3v2, the null byte is a TERMINATOR and in the 2.4.0
version, it's a separator. Ouch! That seems like a big revision and
one that's likely to cause a lot of heartburn across implementations.

Scott> So, if the frame uses ASCII, the termination will be a single-byte
Scott> null character ($00); for Unicode, two null bytes ($00 $00).

Scott> I don't know of any editor, other than hex editors, that
Scott> lets you enter a null byte into a text string, at least not
Scott> without causing undetermined behavior in the editor. Thus,
Scott> for ID3v2.3 tags, if we want to have some sort of
Scott> slimserver-specific interpretation of multiple free-form
Scott> (that is, non-ID3v1-style) genres for a file, then it's
Scott> best we choose a printable character as a separator. Since
Scott> several other ID3v2.3 frames use "/" as a separator between
Scott> entries (TCOM, TEXT, TOLY, TOPE, TPE1, TPOS, TRCK), then it
Scott> seems like an easy extension to support this in TCON as
Scott> well. Again, I would make this a server setting, and only
Scott> do this for ID3v2.3 tags.

But if we do that, then we've created a rival ID3v2-Slimserver
standard, haven't we? Isn't the proper thing to make it up to the
tagging application to choose how to give a print rep to the null
byte, and have the client translate it automagically into the null
byte?

OTOH, the use of a null byte as separator essentially makes the
creation of command-line taggers impossible, so maybe we ought to try
to get the standard changed. Especially since the ID3v2 that support
the complete frameset are command-line taggers!

Scott> Also, in another email in this thread, you mentioned that
Scott> the ID3v2.4 spec deprecates the use of numerical genre
Scott> id's. This isn't entirely accurate. Both ID3v2.3 and
Scott> ID3v2.4 fully support the ID3v1-style numerical genres
Scott> (specified as numeric strings, rather than a single byte as
Scott> in ID3v1). They both allow for specifying one or more such
Scott> numerical genres, intermixed with one (for ID3v2.3) or more
Scott> (for ID3v2.4) plain-text genres.

I shouldn't have used the word "deprecated," which is a term of art
with a specific meaning. However, in the spec it states:

The 'Content type', which ID3v1 was stored as a one byte numeric
value only, is now a string. You may use one or several of the ID3v1
types as numerical strings, or, since the category list would be
impossible to maintain with accurate and up to date categories,
define your own. Example: "21" $00 "Eurodisco" $00

That's not a deprecation technically speaking, but it is a deprecation
in the normal English use of the term --- the spec states that the
numerical scheme is inadequate. I certainly agree with that!

Best,
R

ron 'coyote' lussier
2003-12-29, 10:10
On Dec 29, 2003, at 6:48 AM, rpgoldman (AT) real-time (DOT) com wrote:

> OTOH, the use of a null byte as separator essentially makes the
> creation of command-line taggers impossible, so maybe we ought to try
> to get the standard changed. Especially since the ID3v2 that support
> the complete frameset are command-line taggers!

Not if the command-line tagger translates something else into the
separation (null) byte. For example, the default separator could be a
',', which the app would translate into a null. A parameter could
allow changing the default separator character.

coyote

--- , /),
(( -.((_)) _,) Joyous Solstice!
,\`.' `-','
`.> (,-
,', `._,)
ron lussier / lenscraft (( ) (`--' fine art
photography
67 crescent avenue `'( ) _ _,-.\
sausalito / ca 94965 /,' \( ) `'
http://lenscraft.com/
(( `\
`

rpgoldman@real-time.com
2003-12-29, 11:06
>>>>> "ron" == ron lussier <ron> writes:

ron> On Dec 29, 2003, at 6:48 AM, rpgoldman (AT) real-time (DOT) com wrote:

>> OTOH, the use of a null byte as separator essentially makes the
>> creation of command-line taggers impossible, so maybe we ought to try
>> to get the standard changed. Especially since the ID3v2 that support
>> the complete frameset are command-line taggers!

ron> Not if the command-line tagger translates something else into the
ron> separation (null) byte. For example, the default separator could be a
ron> ',', which the app would translate into a null. A parameter could
ron> allow changing the default separator character.

Quite right. I was corresponding with the author of the "Cultured
Perl: Fun with MP3 and Perl" article, and he pointed out the same
thing:

Perl strings can store \x000 bytes without any problems, because
they are length-based instead of marker-based like normal C
strings.

The way to specify them in the command line would be with a special
marker, e.g. "\x000" and then to convert it to a null byte either
on the AppConfig level or at the application level. Yes, it's a
hack, but there's just no good way to do it otherwise."

I might have a whack at tweaking his autotag.pl script to do this, or
make some kind of front-end to id3v2 (but I don't know what would
happen if I gave null bytes to that app).

That assumes that the slimserver will be able to process these
null-separated values if the command-line app sets them correctly.

R

Scott Haug
2003-12-29, 11:15
Monday, December 29, 2003, 6:48:18 AM, rpgoldman wrote:

>>>>>> "Scott" == Scott Haug <scott (AT) houseofhaug (DOT) net> writes:

rrtc> OK, so if I understand this correctly, it means that in the 2.3.0
rrtc> version of ID3v2, the null byte is a TERMINATOR and in the 2.4.0
rrtc> version, it's a separator. Ouch! That seems like a big revision and
rrtc> one that's likely to cause a lot of heartburn across implementations.

Implementing either spec certainly is not trivial. But the 2.4 spec
was created precisely because of shortcomings in the 2.3 spec (just as
2.3 was a complete reivision of the original id3v2 spec, which became
known as the id3v2.2 spec, even though there was no id3v2.1...). The
"/" character separator is certainly insufficient as a separator (as
any printable character would be), as sometimes a "/" wants to be
interpreted as a "/", not a separator. I think the null-byte separator
was a nice elegant solution to this.

To be clear, the spec version the tag uses is specified in the tag
header. So there should be no confusion when parsing as to how to
interpret the null (or any other) character.

rrtc> But if we do that, then we've created a rival ID3v2-Slimserver
rrtc> standard, haven't we? Isn't the proper thing to make it up to the
rrtc> tagging application to choose how to give a print rep to the null
rrtc> byte, and have the client translate it automagically into the null
rrtc> byte?

In answer to your first question, I don't think we're creating a rival
standard. We're just suggesting that the server optionally interpret a
user-defined character as a separtor for a particular frame. If the
user chooses to enable this, that's their option. We haven't made the
frame unparsable by any other applications.

As for the second question, I'm confused. No tagging application
should be expected to do anything with a null byte in an id3v2.3 tag
other than use it as a string terminator. The spec is clear on this.
That's what we're trying to work around. And why would a client
translate a separator into a null byte? I'm not sure I understand this
question.

rrtc> OTOH, the use of a null byte as separator essentially makes the
rrtc> creation of command-line taggers impossible, so maybe we ought to try
rrtc> to get the standard changed. Especially since the ID3v2 that support
rrtc> the complete frameset are command-line taggers!

As mentioned, I think the null byte separator for 2.4 tags is quite
sufficient. And it certainly doesn't make command-line taggers
impossible. I could certainly see see something along the lines of the
following being supported in a command-line app:

id3tag --genre "Country/Western" --genre "Acoustic Pop" --genre "Disco" myfile.mp3

The application could then turn build a TCON frame with those 3 genres
separated by null characters. In fact, I think it's /easier/ for a
command-line app to support adding arbitrarily many entries in a frame
than a gui application.

As for changing the ID3v2.4 spec, there's already a number of taggers
that support it. To change the spec would be to introduce a new
revision of the spec. And I don't think anyone wants that. The field
is already pretty damn cluttered.

rrtc> That's not a deprecation technically speaking, but it is a deprecation
rrtc> in the normal English use of the term --- the spec states that the
rrtc> numerical scheme is inadequate. I certainly agree with that!

As do I.

-Scott

Scott Haug
2003-12-29, 11:35
Monday, December 29, 2003, 10:06:46 AM, rpgoldman wrote:

>>>>>> "ron" == ron lussier <ron> writes:

rrtc> Quite right. I was corresponding with the author of the "Cultured
rrtc> Perl: Fun with MP3 and Perl" article, and he pointed out the same
rrtc> thing:

rrtc> Perl strings can store \x000 bytes without any problems, because
rrtc> they are length-based instead of marker-based like normal C
rrtc> strings.

rrtc> The way to specify them in the command line would be with a special
rrtc> marker, e.g. "\x000" and then to convert it to a null byte either
rrtc> on the AppConfig level or at the application level. Yes, it's a
rrtc> hack, but there's just no good way to do it otherwise."

rrtc> I might have a whack at tweaking his autotag.pl script to do this, or
rrtc> make some kind of front-end to id3v2 (but I don't know what would
rrtc> happen if I gave null bytes to that app).

I think trying to force multiple genres by feeding null-characters
from the command-line is a bad idea, and will prove to be problematic,
both for the app and the user. For one, it's a non-intuitive
interface. Second, this type of processing is best left to the
application; who knows what type of processing the app does to
construct an actual id3v2 tag frame.

It's best to let the tagging application take care of constructing the
id3v2 frame, while modifying the application to make it easy to
specify multiple entries for frames that support it. As mentioned in
a previous email, I think this is a natural usage for a command-line
app to support:

id3tag --genre "Country/Western" --genre "Acoustic Pop" file.mp3

rrtc> That assumes that the slimserver will be able to process these
rrtc> null-separated values if the command-line app sets them correctly.

If it's id3v2.4-compliant and parsing an id3v2.4 tag, it should. At
worst, it should at least parse the first genre listed. If it doesn't,
a bug should be filed (note my non-delegatory use of the passive
voice...).

-Scott

Roy M. Silvernail
2003-12-29, 13:25
On Monday 29 December 2003 13:35, Scott Haug wrote:

> id3tag --genre "Country/Western" --genre "Acoustic Pop" file.mp3
>
> rrtc> That assumes that the slimserver will be able to process these
> rrtc> null-separated values if the command-line app sets them correctly.
>
> If it's id3v2.4-compliant and parsing an id3v2.4 tag, it should. At
> worst, it should at least parse the first genre listed.

I think worst-case should be to use the last genre listed if it's only going
to handle one. That's how it would probably shake out from a typical
command-line parser. (ultimately it doesn't matter as long as apps are
consistent amongst themselves)