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

James Dunn
2003-12-28, 15:03
BTW - are we ever likely to see a browse by ID3 year tag (preferably for a
range of years) option?


-----Original Message-----
From: discuss-bounces (AT) lists (DOT) slimdevices.com
[mailto:discuss-bounces (AT) lists (DOT) slimdevices.com] On Behalf Of
rpgoldman (AT) real-time (DOT) com
Sent: Sunday, December 28, 2003 8:59 PM
To: Slim Devices Discussion
Subject: Re: [slim] Slimserver feature request -- additional 'browse

>>>>> "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
rrtc> separator would have been null bytes.

Scott> [snip]

rrtc> Of course, I'll have to find a tagger that will put the dratted
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?