Re: Fwd: Re: musicbrowser, metadata
On Mon, Oct 25, 1999 at 10:31:46PM -0400, Blake Winton wrote: > > > up with a library for easily parsing that info as well. The format > > > is no work of art, but it does have some benefits over id3v2: the > > > tag as a whole can vary in size, it comes at the end of the file, > > > and is reasonably easy to parse. > > Everything there sounds cool except "at the end of the file." The > > metadata should go at the beginning, so that you know what the song is > > BEFORE you just spent twenty minutes downloading the whole thing. :) > > That's what HTTP/1.1 Byte-Ranges are for. ;) > > (Gimme the last n bytes of this file...) Don't EVEN get me started about how http isn't the right choice for a streaming protocol. ;) Brett
Re: Fwd: Re: musicbrowser, metadata
but you still have to know how many bytes to ask for... elrod Blake Winton wrote: > > > up with a library for easily parsing that info as well. The format > > > is no work of art, but it does have some benefits over id3v2: the > > > tag as a whole can vary in size, it comes at the end of the file, > > > and is reasonably easy to parse. > > Everything there sounds cool except "at the end of the file." The > > metadata should go at the beginning, so that you know what the song is > > BEFORE you just spent twenty minutes downloading the whole thing. :) > > That's what HTTP/1.1 Byte-Ranges are for. ;) > > (Gimme the last n bytes of this file...) > > Later, > Blake.
Re: Fwd: Re: musicbrowser, metadata
> > up with a library for easily parsing that info as well. The format > > is no work of art, but it does have some benefits over id3v2: the > > tag as a whole can vary in size, it comes at the end of the file, > > and is reasonably easy to parse. > Everything there sounds cool except "at the end of the file." The > metadata should go at the beginning, so that you know what the song is > BEFORE you just spent twenty minutes downloading the whole thing. :) That's what HTTP/1.1 Byte-Ranges are for. ;) (Gimme the last n bytes of this file...) Later, Blake.
Re: Fwd: Re: musicbrowser, metadata
On 23 Oct, Mark B. Elrod wrote: > if i remember we had discussed the fact that when all your interaction with a file is > local it makes sense to just store info on the end. a streaming server should be able > to rearrange the data prior to sending it to optimize streaming. The proposal I have laying around actually allows data at the beginning and at the end. Its up to the person/program writing the tag to decide. Once we get the next beta of freeamp out there, I'll dust off the old proposal and send it out... --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
Re: Fwd: Re: musicbrowser, metadata
>> very much like to have full read/write ID3v2 capabilities in FreeAmp, and if >> you can provide us with a comprehensive library that runs under Linux I'd be >> more than glad to incorporate it into FreeAmp. Any chances of this happening >> in the next week? :-) > >Not a chance. :( I've only started hacking at the code, and from what I see >so far it isn't terribly well implemented. For example, rather than setting >the data members in its classes private, it leaves them public and has the >following comment: > >// *** PRIVATE INTERNAL DATA - DO NOT USE *** PRIVATE INTERNAL DATA - DO NOT USE *** > >Why they wouldn't declare them private is beyond me. Well, they need to be able to modify some class 'private' items from another class. If you make those private you'll see the error messages. Probably team did not know what 'friend class' means, so they came up with this ridiculous 'PRIVATE INTERNAL DATA' thing. -- Valters "WaTT" Vingolds
Re: Fwd: Re: musicbrowser, metadata
if i remember we had discussed the fact that when all your interaction with a file is local it makes sense to just store info on the end. a streaming server should be able to rearrange the data prior to sending it to optimize streaming. elrod Scott Thomas Haug wrote: > On Sat, 23 Oct 1999, Brett Thomas wrote: > > On Sat, Oct 23, 1999 at 09:55:36PM -0500, Scott Thomas Haug wrote: > > > up with a library for easily parsing that info as well. The format is no > > > work of art, but it does have some benefits over id3v2: the tag as a whole can > > > vary in size, it comes at the end of the file, and is reasonably easy to parse. > > > > Everything there sounds cool except "at the end of the file." The > > metadata should go at the beginning, so that you know what the song is > > BEFORE you just spent twenty minutes downloading the whole thing. :) > > > > Brett > > Actually, if it were up to me, I would have include tag information at the > beginning and the end. Information that isn't likely to change or isn't too > big (artist, song title, source, etc.) would go at the beginning (along with > some padding to allow for some change w/o having to rewrite entire file) > basically for the reason you give, and everything else (images, information > that might change frequently) would go at the end of the file. Best of both > worlds kinda thing. Downside is implementation would be trickier. > > -Scott
Re: Fwd: Re: musicbrowser, metadata
On Sat, 23 Oct 1999, Brett Thomas wrote: > On Sat, Oct 23, 1999 at 09:55:36PM -0500, Scott Thomas Haug wrote: > > up with a library for easily parsing that info as well. The format is no > > work of art, but it does have some benefits over id3v2: the tag as a whole can > > vary in size, it comes at the end of the file, and is reasonably easy to parse. > > Everything there sounds cool except "at the end of the file." The > metadata should go at the beginning, so that you know what the song is > BEFORE you just spent twenty minutes downloading the whole thing. :) > > Brett Actually, if it were up to me, I would have include tag information at the beginning and the end. Information that isn't likely to change or isn't too big (artist, song title, source, etc.) would go at the beginning (along with some padding to allow for some change w/o having to rewrite entire file) basically for the reason you give, and everything else (images, information that might change frequently) would go at the end of the file. Best of both worlds kinda thing. Downside is implementation would be trickier. -Scott
Re: Fwd: Re: musicbrowser, metadata
On Sat, Oct 23, 1999 at 09:55:36PM -0500, Scott Thomas Haug wrote: > up with a library for easily parsing that info as well. The format is no > work of art, but it does have some benefits over id3v2: the tag as a whole can > vary in size, it comes at the end of the file, and is reasonably easy to parse. Everything there sounds cool except "at the end of the file." The metadata should go at the beginning, so that you know what the song is BEFORE you just spent twenty minutes downloading the whole thing. :) Brett
Re: Fwd: Re: musicbrowser, metadata
On Sat, 23 Oct 1999, Mayhem & Chaos Coordinator wrote: > Perfect -- I'll get it taken care of before we release 2.0 on November 15th. Great! The day after my birthday. What a nice present! > > That was one of the reasons, but more importantly I tried to run the id3v2 > code on linux about a year ago with dismal results. Just before I wrote the > cheese-ass-let's-read-only-the-most-crucial-T-tags-id3v2-read-only > implementation I checked the website for an update and was pointed to > MusicMatch, where I could find no mention of an updated library. We would > very much like to have full read/write ID3v2 capabilities in FreeAmp, and if > you can provide us with a comprehensive library that runs under Linux I'd be > more than glad to incorporate it into FreeAmp. Any chances of this happening > in the next week? :-) Not a chance. :( I've only started hacking at the code, and from what I see so far it isn't terribly well implemented. For example, rather than setting the data members in its classes private, it leaves them public and has the following comment: // *** PRIVATE INTERNAL DATA - DO NOT USE *** PRIVATE INTERNAL DATA - DO NOT USE *** Why they wouldn't declare them private is beyond me. Plus I want to use automake & autoconf so that it'll compile nicely into a shared lib, but my experience with those tools is slim, so I'm learning that as well. Finally, I'm having to come up with unusual tactics to gain access to my computer, as my wife has started learning the wonders of the gimp and staroffice. So, in short, hopefully within the next couple weeks, but certainly not bythis week. > > > > Do you have a vested interest in ID3v2? Personally, I cannot stand ID3v2. > Its obfuscated, too complicated and it tries to save every last possible bit > of space at the expense of ease of implemtation. (I have written a complete > ID3v2 library in Perl, so I *know*) > I have no vested interest, other than I have many songs with id3v2 tags. I wanted a tagging system that isn't bound by the ridiculous limitations of id3v1, and id3v2 seemed like the obvious choice. The only other tagging system that I know of (besides lyric tags) is musicmatch's original tagging format, before they assumed control of id3v2 (the free downloads at musicmatch.com is where I first experienced the joys of mp3 music, many moons ago). I've actually been trying to reverse-engineer the format for this format, and possibly coming up with a library for easily parsing that info as well. The format is no work of art, but it does have some benefits over id3v2: the tag as a whole can vary in size, it comes at the end of the file, and is reasonably easy to parse. In many ways its like an id3v1 tag with variable sized fields and more of them. Since musicmatch never made the specs for this format public, my knowledge of their system isn't complete, but it is about 95%. > We could do this much easier with XML. It could be much more powerful and > the only ID3v2 code we would have to write it code to translate the existing > tags to the XML format. I've even got a rough draft of a proposed > replacement for ID3v2 using XML. I really think it would be worth it for us > to consider doing this. We can have all the features of ID3v2 and a ton more > with a lot of flexibility, with much less code to write. A good standards > document (RFC?) and a bare minimum of code and an XML parser. (And half a > tank of gas) Isn't it "A full tank of gas, a half a pack of cigarettes..."? Or did I assume the wrong allusion? > > Anyone interested? I'm very interested. I know little of XML, but it doesn't look all that difficult to learn. If you could make your tagging proposal available online, I'd love to look at it. > > > > --ruaok Freezerburn! All else is only icing. -- Soul Coughing > > Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
Re: Fwd: Re: musicbrowser, metadata
> I'm pretty sure that's all winamp does, too. But it still plays. :) I've > posted a slightly more informative report to bugzilla, along with a link to a > file that has an offending tag. Perfect -- I'll get it taken care of before we release 2.0 on November 15th. > > I don't remember why we made the decision not to use the id3lib stuff, > > and roll our own. It may have been because we originally had the > > philosophy that we were trying to avoid users having to get 57 > > not-commonly-installed libraries before they could compile (this is That was one of the reasons, but more importantly I tried to run the id3v2 code on linux about a year ago with dismal results. Just before I wrote the cheese-ass-let's-read-only-the-most-crucial-T-tags-id3v2-read-only implementation I checked the website for an update and was pointed to MusicMatch, where I could find no mention of an updated library. We would very much like to have full read/write ID3v2 capabilities in FreeAmp, and if you can provide us with a comprehensive library that runs under Linux I'd be more than glad to incorporate it into FreeAmp. Any chances of this happening in the next week? :-) > Well, the id3v2 development has been stagnant for almost a year, at least > according to the id3.org site and the date of the last id3lib update. As > mentioned previously, it seems that musicmatch has taken over the id3lib > project, but I haven't been able to find anything on their site that mentions > continued development with the library. This itch is a particularly important > one to me, as I have quite a few songs with large id3v2 tags and no linux > player (to my knowledge) that plays them correctly. I'll continue hacking > id3lib to make it usable in linux, and if anyone decides that using id3lib in > freeamp would be a good idea, I'd be glad to help with this effort. Do you have a vested interest in ID3v2? Personally, I cannot stand ID3v2. Its obfuscated, too complicated and it tries to save every last possible bit of space at the expense of ease of implemtation. (I have written a complete ID3v2 library in Perl, so I *know*) We could do this much easier with XML. It could be much more powerful and the only ID3v2 code we would have to write it code to translate the existing tags to the XML format. I've even got a rough draft of a proposed replacement for ID3v2 using XML. I really think it would be worth it for us to consider doing this. We can have all the features of ID3v2 and a ton more with a lot of flexibility, with much less code to write. A good standards document (RFC?) and a bare minimum of code and an XML parser. (And half a tank of gas) Anyone interested? --ruaok Freezerburn! All else is only icing. -- Soul Coughing Robert Kaye -- [EMAIL PROTECTED] http://moon.eorbit.net/~robert
Re: Fwd: Re: musicbrowser, metadata
On Sat, 23 Oct 1999, Brett Thomas wrote: > On Sat, Oct 23, 1999 at 08:50:23AM -0500, Scott Thomas Haug wrote: > > The Winamp test doesn't mean much, unless they've added id3v2 support, > recently. Last I checked, they just skipped stuff in the id3v2 frame, > entirely. I'm pretty sure that's all winamp does, too. But it still plays. :) I've posted a slightly more informative report to bugzilla, along with a link to a file that has an offending tag. > >My assumption is that you aren't using the id3lib, available on the id3.com > > I assume that you mean the id3.org website. Check this out: Oops. s/\.com/\.org/ > > We donate the space to host id3.org and id3v2.org (and id3v3.org, if > anything ever happens, there). :) > Forgive my ignorance. Looks like I'm preaching to the choir... :) > > I don't remember why we made the decision not to use the id3lib stuff, > and roll our own. It may have been because we originally had the > philosophy that we were trying to avoid users having to get 57 > not-commonly-installed libraries before they could compile (this is > more of an issue for Linux than Windows, obviously). Anyone remember > why we did this? Generally speaking, I'm a big fan of integrating > existing stuff, rather than rewriting it. At the time, there wasn't > much id3v2 support, so we MAY have decided to roll our own so that > there would be two complete implementations, to help hammer out > compatability issues. Well, the id3v2 development has been stagnant for almost a year, at least according to the id3.org site and the date of the last id3lib update. As mentioned previously, it seems that musicmatch has taken over the id3lib project, but I haven't been able to find anything on their site that mentions continued development with the library. This itch is a particularly important one to me, as I have quite a few songs with large id3v2 tags and no linux player (to my knowledge) that plays them correctly. I'll continue hacking id3lib to make it usable in linux, and if anyone decides that using id3lib in freeamp would be a good idea, I'd be glad to help with this effort. > > Brett > --- > Vice President, Technology, EMusic.com, Inc. -- http://www.emusic.com Thanks for your response. -Scott
Re: Fwd: Re: musicbrowser, metadata
On Sat, Oct 23, 1999 at 08:50:23AM -0500, Scott Thomas Haug wrote: > I'm assuming there's nothing wrong with the format of the tags themselves, > since they were made with musicmatch jukebox and are playable within winamp. The Winamp test doesn't mean much, unless they've added id3v2 support, recently. Last I checked, they just skipped stuff in the id3v2 frame, entirely. > My assumption is that you aren't using the id3lib, available on the id3.com > website. If this is an incorrect assumption, please let me know. I am > currently hacking the library so that it works on linux and comes in a nice gnu > installer tarball, using automake, autoconf, and such. I'm pretty sure the > current id3lib download has a windows dll already compiled. This library has > been released to the public domain, so I was wondering if there was any > discussion/consideration for using it in freeamp. As I understand it, > Musicmatch has taken up "official" development of the library, but I haven't > heard of any public announcement from them, either about their assuming > responsibility for the library or their plans for future development of it. I assume that you mean the id3.org website. Check this out: ~$ nslookup www.freeamp.org Name:fatman.freeamp.org Address: 209.249.146.48 Aliases: www.freeamp.org ~$ nlsookup www.id3.org Name:fatman.id3.org Address: 209.249.146.48 Aliases: www.id3.org We donate the space to host id3.org and id3v2.org (and id3v3.org, if anything ever happens, there). :) > I know little about the freeamp codebase, but if using the id3lib for better > id3v1/2 tag support would interest folk here, I would be happy to try and help > integrate it into the project. I don't remember why we made the decision not to use the id3lib stuff, and roll our own. It may have been because we originally had the philosophy that we were trying to avoid users having to get 57 not-commonly-installed libraries before they could compile (this is more of an issue for Linux than Windows, obviously). Anyone remember why we did this? Generally speaking, I'm a big fan of integrating existing stuff, rather than rewriting it. At the time, there wasn't much id3v2 support, so we MAY have decided to roll our own so that there would be two complete implementations, to help hammer out compatability issues. Brett --- Vice President, Technology, EMusic.com, Inc. -- http://www.emusic.com
