From andrew.kernahan at btinternet.com Wed Jan 25 12:07:27 2006 From: andrew.kernahan at btinternet.com (Andy Kernahan) Date: Wed, 25 Jan 2006 20:07:27 -0000 Subject: [ID3 Dev] First byte of the first frame: the inevitable byte (revised) References: <20060125193558.HOTA25752.gx5.fuse.net@avoca> Message-ID: <001101c621ea$f992a900$0500000a@MARVIN> The sync-signal has a byte pattern of 0xFFE0. Scanning the file stream for this pattern will reveal the position of the first frame within the mp3 file. Andy. ----- Original Message ----- From: Mitchell S. Honnert To: id3v2 at id3.org Sent: Wednesday, January 25, 2006 7:35 PM Subject: RE: [ID3 Dev] First byte of the first frame: the inevitable byte (revised) If all you want to do is find the first audio frame, you don't necessarily need to know the ID3v2 tag length. (If you do need the length, it's clearly spelled out in the spec.) Do a search on MPEG header and you'll find the byte pattern which identifies the start of an audio frame. One location for this information is at http://www.mp3-tech.org/ in the Programmer's Corner section. (In writing my .NET tag editor library, I decided to add support for MPEG data like bit rate and frequency, and this is the page I used as a reference.) Mitchell S. Honnert www.UltraID3Lib.com ------------------------------------------------------------------------------ From: Silas Pradetto [mailto:silas at sonoroussound.com] Sent: Wednesday, January 25, 2006 2:22 PM To: id3v2 at id3.org Subject: [ID3 Dev] First byte of the first frame: the inevitable byte (revised) thanks, the files encoded by different encoders I would consider to be different, i only want to detect files that i may have downloaded twice and are in different dirs, and someone may have changed the tag on one not the other, but the file is the same otherwise. thanks for the suggestion on the already-done dup remover, as i have no real time for writing this stuff anymore, the other question is how to find the length of the ID3v2 tag??? thanks again, silas If you really want to reinvent the wheel you can -- you have to determine how long the ID3v2 tag is, skip that, then read the rest of the file (excepting the last 256 bytes if it has an ID3V1 tag). How you do this depends entirely on the library (if any) you use. Note that if all you do is a byte-by-byte comparison then you still won't detect dupes if the files were encoded by different encoders, or at different bitrates, or various other issues. If you don't want to reinvent the wheel, then go take a look at musicbrainz.org -- they've already done this. And taken care of the various issues I listed above. On 1/25/06, Silas Pradetto wrote: I recently became added to this system of emails, and I am trying to write a program to find duplicates in MP3's. I wish to only take into consideration the actual song data, not bytes of any tags. Therefore, how do I find the first byte in the file of actual song data, ie the first byte of the first frame? I want to be able to detect duplicates that have different tags but are the exact same audio information. Also, to make the program faster, I would like to know where to find certain info such as bitrate, length in seconds, etc, so when I am scanning my 100000 song library I don't have to check bytes if the songs are obviously dissimilar. Thanks very much. Oh, and I mostly do VB 6, though I do know some C++, so if you are going to talk about file I/O stuff please refer to VB if you can. Silas --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From id3v2 at audiott.com Thu Jan 19 08:36:42 2006 From: id3v2 at audiott.com (Michal Vician) Date: Thu, 19 Jan 2006 17:36:42 +0100 (CET) Subject: [ID3 Dev] ID3v2 extensions to support the visually impaired In-Reply-To: <6.1.2.0.2.20051214111948.02ec8cd8@pop3> References: <6.1.2.0.2.20051214111948.02ec8cd8@pop3> Message-ID: <34263.195.91.64.54.1137688602.squirrel@195.91.64.54> Hi, This sounds really good! Just imagine a portable MP3 player with support of audible metadata.. Then the visually impaired will press a "special button" which will simply play all available audible metadata of MP3 - nice idea, isn't it ? :-) > I've started work on a technical proposal for a "Audio Text" frame based > on the following requirements... The requirements seems to be ok. I will let you know if I have some comments to this. If "Audio Text" frame is completed I will certainly try to implement it into my application. I'm looking forward the technical proposal. PS: Is an audible metadata your idea? Best regards Miso > Colleagues, > > I would like to propose a new task for the group - to provide support > within ID3v2 for the visually impaired. This is an important issue for > broadcasters and may also be of concern to audio book providers. > > The idea would be to provide an audible alternative to existing ID3v2 > frames, allowing a listener to navigate through the menus and listings of > an audio player by sound alone. Although primarily intended for the > visually impaired, this feature might also be popular with other users and > useful for media players with no visual display. > > Although computer generated speech is a possible approach, I think this > would probably require too much processing power to be implemented within > a typical MP3 player. A more practical approach would be to provide audio > clips within ID3v2 frames which the player can play to accompany the > presentation of the equivalent textual metadata. > > The audible metadata clips could be obtained in several ways: > - they could be added by the publisher > - they could be downloaded from third party databases > - they could be added by a computer generated speech system running on the > PC used to upload content to the audio player > > I've started work on a technical proposal for a "Audio Text" frame based > on the following requirements: > - must be able to provide an audible alternative for any existing type of > text frame. > - must not preclude the provision of more than one language. > - must be backwards-compatible with existing v2.3 and v2.4 specifications. > - there should not be a requirement to provide an audible equivalent for > every frame in a tag. > > I would be very interested to hear whether you think the work would be > worthwhile and any ideas or requirements you have. > > Best regards, > > Chris --- Michal Vician id3v2 at audiott.com http://www.audiott.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From py.thoulon at gmail.com Sun Jan 15 21:57:08 2006 From: py.thoulon at gmail.com (Pyt) Date: Mon, 16 Jan 2006 06:57:08 +0100 Subject: [ID3 Dev] id3v2.4 & frame sizes? In-Reply-To: <6BC2D0DC-9D82-4E36-A894-AB868A688294@steelskies.com> References: <6BC2D0DC-9D82-4E36-A894-AB868A688294@steelskies.com> Message-ID: Yes your description of what the synch-safe size should look like is correct. However, I remember seeing a discussion on this very list about how bad the ITunes v2.4 implementation was, and in particular, that it did *not* implement synch-safe frame sizes... And also somebody mentioning the exact same algorithm that you describe: first try the synch-safe size and see if it makes sense (e.g., if the following data looks like a new frame), then try the non synch-safe size, then declare the frame corrupt. The problem is that even if a synch-safe integer as 0 as most significant bit for each bytes, not everything that exhibits this pattern is a synch-safe integer. So trial and error is the only thing that's got a chance to work, although in some rare cases it might fail (e.g., false detection of a valid frame). Regards, Pyt. On 1/15/06, Jonathan del Strother wrote: > > I'm seeing a couple of MP3s that don't have synch-safe frame sizes, > and wanted to check that I'm reading the specification right. For > v2.4, all frame sizes should have a 0 at the start of each byte, right? > > I'm pretty sure that's correct, but I tried persuading iTunes to > convert the tag to 2.3 and then back to 2.4, and the frame size > remains non-synch-safe - I'm a little surprised that iTunes doesn't > fix it. > > > Any idea how common a problem this is? I'm tempted to read the size > as a non-synch-safe integer, and see if that offset then lands me on > what looks like a new frame id. Or is that a horribly bad idea? > > Thanks, > Jon > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From py.thoulon at gmail.com Tue Jan 17 00:23:26 2006 From: py.thoulon at gmail.com (Pyt) Date: Tue, 17 Jan 2006 09:23:26 +0100 Subject: [ID3 Dev] compare mp3's irrespective of tags In-Reply-To: <20060116171304.44053.qmail@web52712.mail.yahoo.com> References: <20060116171304.44053.qmail@web52712.mail.yahoo.com> Message-ID: ID3-TagIt (http://www.id3-tagit.de) includes a function to find duplicate files based on a checksum. Check it out. Pyt. On 1/16/06, Keith Reynolds wrote: > > Hello, > I'm wondering if there's any APIs out there that return the playable > binary data of an mp3 (minus the ID3 tags). I have a large library > with some duplicates and simply hashing the files to find duplicates > isn't working (as I've updated a good number of ID3s and I changed the > filenames). > > If there is no such API can you point me in the right direction to > include all ID3 tag fomats in my coding? > > Thanks, > Keith > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch at honnert.com Fri Jan 13 23:36:08 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Sat, 14 Jan 2006 02:36:08 -0500 Subject: [ID3 Dev] TCON confusion In-Reply-To: <000001c61426$9bc883c0$5136b818@cleffedup> Message-ID: <20060114073600.GQUX29854.gx4.fuse.net@avoca> OK, I've decided to revisit something that's been bugging me for a long time. The TCON "genre" section in the standards document states that you can store multiple genre values in the frame, but after several readings, I still can't say exactly how to do this. See below for the TCON frame section (from http://www.id3.org/id3v2.3.0.html#TCON) in its entirety and my inline questions and comments... >The 'Content type', which previously was stored as a one byte numeric value >only, is now a numeric string. So far, so good. Genres will be represented with numbers. >You may use one or several of the types as ID3v1.1 did What? This sentence appears to imply that ID3v1.1 supported "several" genres, but it clearly does not. One can even read into this sentence that the ID3v2.3 implements multiple genres in the same manner that ID3v1.1 did. >or, since the category list would be impossible to maintain with accurate >and up to date categories, define your own. Now we're getting somewhere. We don't have to use numbers from a predefined list. We can define out own genres. Cool. >References to the ID3v1 genres can be made by, as first byte, enter "(" >followed by a number from the genres list (appendix A) and ended with a ")" >character. This is optionally followed by a refinement, e.g. "(21)" or >"(4)Eurodisco". This is where the uncertainty really starts for me. The "(4)" represents Disco (from Appendix A) and "Eurodisco" is the refinement. The word "refinement" combined with the example implies that you aren't supposed to define your *own* genres, but only new *subcategories* of the genres in Appendix A. But all editors for ID3v2.3 have genre as free-form text. But if genre is truly meant to be free-form, why bother with the number in the first place? Why open up a situation where you can combine the genre number for with a totally contradictory refinement i.e. "(15)Country and Western"? What would you display given this genre: "Rap", "Country and Western", or "Rap (Country and Western)"? >Several references can be made in the same frame, e.g. "(51)(39)". OK. Here's the part I'm interested in: multiple genres. But there are no details around the "refinements" i.e. how to handle custom genres. Common sense would say that multiple genres would appear like so... "(51)Southern Techno-Industrial(39)Funny Noises" But how would I implement multiple genres in a single frame if I chose to do away with the number, as most of the popular audio players appear to do? It seems like I can't. Even though they are ignored, it looks like I'd have to put some dummy genre numbers in there just to act as delimiters. Like so... "(12)Songs to brush my teeth to(12)A bright coloured fish" >If the refinement should begin with a "(" character it should be replaced >with "((", e.g. "((I can figure out any genre)" or "(55)((I think...)". >The following new content types is defined in ID3v2 and is implemented in >the same way as the numerig content types, e.g. "(RX)". >RX Remix >CR Cover These two sections make sense. (I actually support the Remix and Cover flags in my lib, but I don't know of any other libs or apps that do.) And to confuse matters even worse, I loaded up a file edited using ID3-TagIT (which is the only application that I can find that supports multiple genres) in a binary editor and discovered that this application uses null chars to delimit the multiple genres. This seems like the easiest way to implement multiple genres to me, but in no reading of the TCON standard, do I get to use null-terminated strings. So...how should I implement multiple genres to best follow the standard? I know I'm being pedantic about this, but I don't want to interpret the TCON section one way, implement it in my ID3 library, and later discover some popular library or audio application that supports multiple genres in a completely different way. Thanks, Mitchell S. Honnert www.UltraID3Lib.com --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From tsorensen at gmail.com Wed Jan 25 11:17:49 2006 From: tsorensen at gmail.com (Tom Sorensen) Date: Wed, 25 Jan 2006 14:17:49 -0500 Subject: [ID3 Dev] First byte of the first frame: the inevitable byte In-Reply-To: <16683239.149921138216310329.JavaMail.servlet@perfora> References: <16683239.149921138216310329.JavaMail.servlet@perfora> Message-ID: <4da424620601251117j7870affft3acecd5c4675474f@mail.gmail.com> If you really want to reinvent the wheel you can -- you have to determine how long the ID3v2 tag is, skip that, then read the rest of the file (excepting the last 256 bytes if it has an ID3V1 tag). How you do this depends entirely on the library (if any) you use. Note that if all you do is a byte-by-byte comparison then you still won't detect dupes if the files were encoded by different encoders, or at different bitrates, or various other issues. If you don't want to reinvent the wheel, then go take a look at musicbrainz.org -- they've already done this. And taken care of the various issues I listed above. On 1/25/06, Silas Pradetto wrote: > > I recently became added to this system of emails, and I am trying to write > a program to find duplicates in MP3's. I wish to only take into > consideration the actual song data, not bytes of any tags. Therefore, how do > I find the first byte in the file of actual song data, ie the first byte of > the first frame? I want to be able to detect duplicates that have different > tags but are the exact same audio information. Also, to make the program > faster, I would like to know where to find certain info such as bitrate, > length in seconds, etc, so when I am scanning my 100000 song library I don't > have to check bytes if the songs are obviously dissimilar. Thanks very much. > Oh, and I mostly do VB 6, though I do know some C++, so if you are going to > talk about file I/O stuff please refer to VB if you can. > > Silas > --------------------------------------------------------------------- To > unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, > e-mail: id3v2-help at id3.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From tsorensen at gmail.com Tue Jan 3 08:14:08 2006 From: tsorensen at gmail.com (Tom Sorensen) Date: Tue, 3 Jan 2006 11:14:08 -0500 Subject: [ID3 Dev] ID3V2 tag length In-Reply-To: <000001c6107f$8e4a8fe0$7e624f51@newxp> References: <000001c6107f$8e4a8fe0$7e624f51@newxp> Message-ID: <4da424620601030814m6fb02677j9ff273501481105d@mail.gmail.com> ID3v2 Tags are variable length, but you'd be very hardpressed to beat ID3v1 in size -- ID3v1 tags are always 128 bytes. Most ID3v2 tags are much larger than this, and are often padded out to 2k or 4k in length. That said, you're not going to see much savings from worrying over tag lengths -- even if you assume that each ID3v2 tag is 2k in size (much of which is padding, and unlikely to be stored by your player), then you'd have to have 1000 songs to save 2 MB of disk space. If you only use ID3v1 tags then any long song/album/artist names will be chopped at 30 characters and you'll be limited to the predefined genres. Tom Sorensen On 1/3/06, Ray MONK wrote: > > Congratulations on your excellent site! > > I have recently updated my Creative Jukebox from 6GB to 40GB in order to > store more MP3's. I understand that the tags are held in RAM and therefore I > wish to keep the tags as small as possible in order that I may store the > maximum number of songs. Presumably the RAM holds the TAG details plus the > disk address where the song is stored. Can anyone tell me (please) if ID3v2 > are variable length records as opposed to v1 which appear to be fixed > length. > Any info would be appreciated' > > Ray > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mitch at honnert.com Tue Jan 3 08:18:33 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Tue, 3 Jan 2006 11:18:33 -0500 Subject: [ID3 Dev] ID3V2 tag length References: <000001c6107f$8e4a8fe0$7e624f51@newxp> Message-ID: <001f01c61081$5806e3f0$40010105@kendle.com> The ID3v2 tag is most definately variable length. The v2 tag can store any number of "frames" which themselves are variable length. See the standards documents here http://www.id3.org/develop.html for more details. Mitchell S. Honnert www.UltraID3Lib.com ----- Original Message ----- From: Ray MONK To: id3v2 at id3.org Sent: Tuesday, January 03, 2006 11:05 AM Subject: [ID3 Dev] ID3V2 tag length Congratulations on your excellent site! I have recently updated my Creative Jukebox from 6GB to 40GB in order to store more MP3's. I understand that the tags are held in RAM and therefore I wish to keep the tags as small as possible in order that I may store the maximum number of songs. Presumably the RAM holds the TAG details plus the disk address where the song is stored. Can anyone tell me (please) if ID3v2 are variable length records as opposed to v1 which appear to be fixed length. Any info would be appreciated' Ray -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch at honnert.com Sun Jan 15 09:54:31 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Sun, 15 Jan 2006 12:54:31 -0500 Subject: [ID3 Dev] id3v2.4 & frame sizes? In-Reply-To: <6BC2D0DC-9D82-4E36-A894-AB868A688294@steelskies.com> Message-ID: <20060115175422.JULB24344.gx6.fuse.net@avoca> Jonathan, while I can't answer your question directly, I can give some background that might help a little. >I'm a little surprised that iTunes doesn't fix it. In my experience iTunes and the other major audio players follow the ID3 standard very well, but there *are* exceptions. iTunes for example will insert a completely non-standard TCMP frame if you check "Part of a compilation" in the ID3 edit form. So, if the authors of iTunes are willing to disregard the standard in this way, maybe they disregarded or overlooked the specification about synch-safe frame sizes. (BTW, I'm reading the v2.4 spec the same way you are about synch-safe frame sizes.) It would be a shame if one of the most popular audio players corrupted the v2.4 standard in the way you describe. But I wouldn't be surprised if it did. Mitchell S. Honnert www.UltraID3Lib.com -----Original Message----- From: Jonathan del Strother [mailto:maillist at steelskies.com] Sent: Sunday, January 15, 2006 10:54 AM To: id3v2 at id3.org Subject: [ID3 Dev] id3v2.4 & frame sizes? I'm seeing a couple of MP3s that don't have synch-safe frame sizes, and wanted to check that I'm reading the specification right. For v2.4, all frame sizes should have a 0 at the start of each byte, right? I'm pretty sure that's correct, but I tried persuading iTunes to convert the tag to 2.3 and then back to 2.4, and the frame size remains non-synch-safe - I'm a little surprised that iTunes doesn't fix it. Any idea how common a problem this is? I'm tempted to read the size as a non-synch-safe integer, and see if that offset then lands me on what looks like a new frame id. Or is that a horribly bad idea? Thanks, Jon --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From parturi at bairesweb.com Mon Jan 23 15:18:07 2006 From: parturi at bairesweb.com (Pablo L. Arturi) Date: Mon, 23 Jan 2006 20:18:07 -0300 Subject: [ID3 Dev] Compiling with make id3lib-3.8.3 over FC3 Message-ID: <067101c62073$48f80720$0400a8c0@bworg196ib52so> Hello people, I don't know if this is the right place to ask a install question, but I haven't found any place other than this and this is driving me crazy. I am trying to install id3lib-3.8.3, I do ./configure and verything seems ok. I then run make, and a lot of this warnings came up: cc1plus: warning: command line option "-Wmissing-declarations" is valid for C/ObjC but not for C++ Since make seems to end ok, I do "make check" and I get the following errors: cc1plus: warning: command line option "-Wmissing-declarations" is valid for C/ObjC but not for C++ test_io.cpp: In function `int main(size_t, const char**)': test_io.cpp:27: error: `cin' undeclared (first use this function) test_io.cpp:27: error: (Each undeclared identifier is reported only once for each function it appears in.) test_io.cpp:119: error: `hex' undeclared (first use this function) test_io.cpp:119: error: `dec' undeclared (first use this function) make[2]: *** [test_io.o] Error 1 make[2]: Leaving directory `/root/software-install/id3lib-3.8.3/examples' make[1]: *** [check-am] Error 2 make[1]: Leaving directory `/root/software-install/id3lib-3.8.3/examples' make: *** [check-recursive] Error 1 Coud someone please help me? Thank you in advance, and if this isn't the right place to ask, please accept my apologizes. Regards, Pablo -------------- next part -------------- An HTML attachment was scrubbed... URL: From silas at sonoroussound.com Wed Jan 25 11:11:50 2006 From: silas at sonoroussound.com (Silas Pradetto) Date: Wed, 25 Jan 2006 14:11:50 -0500 Subject: [ID3 Dev] First byte of the first frame: the inevitable byte Message-ID: <16683239.149921138216310329.JavaMail.servlet@perfora> An HTML attachment was scrubbed... URL: From mitch at honnert.com Sat Jan 14 10:48:47 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Sat, 14 Jan 2006 13:48:47 -0500 Subject: [ID3 Dev] TCON confusion In-Reply-To: Message-ID: <20060114184839.WQQE25752.gx5.fuse.net@avoca> Using a null-separated list of strings (which from my reading is what is specified in the v2.4 TCON spec) would have the advantage of being easy to implement and that it would follow the only implementation I know about (ID3-TagIT), but there just seems to be something wrong with diverging from the standard so much. In order to get an idea of exactly how to implement a particular frame, I have examined frames created by other libraries or audio players. But this was just to "fill in the gaps" and better understand what was in the standard. To date, I?ve never come close to intentionally breaking the standard. And since the v2.3 standard doesn?t mention anything about null-terminated strings, I would have a bad feeling about implementing such a scheme. On the other hand, a standard is only as good as its adherence. I would bow to precedent; I just want to make sure that if I?m going to contradict the standard, that there really is an established precedent and that I wouldn?t be contributing to non-compliance. So, other than ID3-TagIT, what are some of the other libraries and or audio applications that support multiple genres? If I can see some other multi-genre frames for myself, I?d feel a lot better about implementing this scheme. Again, this may seem way overcautious, but I?ve been working with the ID3 standard so long, I've found myself getting a bit protective of it. Thanks, - Mitchell S. Honnert ________________________________________ From: Pyt [mailto:py.thoulon at gmail.com] Sent: Saturday, January 14, 2006 4:20 AM To: id3v2 at id3.org Subject: Re: [ID3 Dev] TCON confusion I've seen most apps deal with it as a null-separated list of strings, and that's how I deal with it. Some of them will only retain the first value. I had never really paid attention at the wording in the spec, and agree it is somewhat confusing. The v2.4 wording is not much clearer... ? Pyt. ? On 1/14/06, Mitchell S. Honnert wrote: OK, I've decided to revisit something that's been bugging me for a long time.??The TCON "genre" section in the standards document states that you can store multiple genre values in the frame, but after several readings, I still can't say exactly how to do this. --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From pfurrie at hotmail.com Sun Jan 29 09:05:00 2006 From: pfurrie at hotmail.com (Pat Furrie) Date: Sun, 29 Jan 2006 12:05:00 -0500 Subject: ID3 Message-ID: Dear Mr. O?Neill, I?m trying to find Martin Nilsson, who is apparently the creator of ID3v2, and I?m hoping you are acquainted with him. I?m hoping to email him regarding the current standard. I?ve attempted to send him an email to the address he has listed on the ID3.org website, but it came back as undeliverable. If you do have Mr. Nilsson?s email address, I?d appreciate it if you could forward this email to him. Thanks in advance for your help. Pat Furrie pfurrie at hotmail.com -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.375 / Virus Database: 267.14.23/243 - Release Date: 1/27/2006 -------------- next part -------------- An HTML attachment was scrubbed... URL: From py.thoulon at gmail.com Sat Jan 14 01:19:43 2006 From: py.thoulon at gmail.com (Pyt) Date: Sat, 14 Jan 2006 10:19:43 +0100 Subject: [ID3 Dev] TCON confusion In-Reply-To: <20060114073600.GQUX29854.gx4.fuse.net@avoca> References: <000001c61426$9bc883c0$5136b818@cleffedup> <20060114073600.GQUX29854.gx4.fuse.net@avoca> Message-ID: I've seen most apps deal with it as a null-separated list of strings, and that's how I deal with it. Some of them will only retain the first value. I had never really paid attention at the wording in the spec, and agree it is somewhat confusing. The v2.4 wording is not much clearer... Pyt. On 1/14/06, Mitchell S. Honnert wrote: > > OK, I've decided to revisit something that's been bugging me for a long > time. The TCON "genre" section in the standards document states that you > can store multiple genre values in the frame, but after several readings, > I > still can't say exactly how to do this. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mitch at honnert.com Wed Jan 25 12:52:02 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Wed, 25 Jan 2006 15:52:02 -0500 Subject: [ID3 Dev] Image frame question In-Reply-To: Message-ID: <20060125205202.KKI3001.gx6.fuse.net@avoca> >The presence of the string "APIC" as the identifer of a frame >in the tag, you mean. Uh...yes, that's what I meant to say. :-) Thanks, Mitchell S. Honnert www.UltraID3Lib.com -----Original Message----- From: Paul Grebenc [mailto:jid3 at blinkenlights.org] Sent: Wednesday, January 25, 2006 3:41 PM To: id3v2 at id3.org Subject: RE: [ID3 Dev] Image frame question On Wed, 25 Jan 2006, Mitchell S. Honnert wrote: > Yes, there is a simple criterion, the presence of the string "APIC" in the > tag. The presence of the string "APIC" as the identifer of a frame in the tag, you mean. You can't just do a string match against the entire tag, because "APIC" could be contained in any of the text fields of another frame. You can't avoid having to know something about the structure of a tag, if you're going to determine the presence of a particular frame. Paul --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From mitch at honnert.com Wed Jan 25 12:10:18 2006 From: mitch at honnert.com (Mitchell S. Honnert) Date: Wed, 25 Jan 2006 15:10:18 -0500 Subject: [ID3 Dev] Image frame question In-Reply-To: <30CE0C8B4E0D0B41928DE8C587C3F375024985A4@csifiapp6105.oa.caiso.com> Message-ID: <20060125201018.AUM3001.gx6.fuse.net@avoca> >Is the