From fiji at ayup.limey.net Thu May 12 19:31:47 2005 From: fiji at ayup.limey.net (Ben Bennett) Date: Thu, 12 May 2005 22:31:47 -0400 Subject: [ID3 Dev] question about compressed unsynchronized frames In-Reply-To: <4283F773.2000609@wan-hi.de> References: <4281D806.50708@wan-hi.de> <20050511134014.GA18643@ayup.limey.net> <4283F773.2000609@wan-hi.de> Message-ID: <20050513023147.GA26834@ayup.limey.net> [I have cc'ed info at getid3.org to try to get them to weigh in on interpreting the 2.4 spec since they seem to have a robust parser] On Fri, May 13, 2005 at 02:40:19AM +0200, Wan-Hi wrote: > But in my opinion you are wrong when saying that frame information > fields are not unsynced. 4.1 says that additional frame information > fields are inserted between the frame header and the actual frame data. > These fields are not subject to encryption or compression. However, they > are subject to unsynchronisation (4.1.2 'Frame Format Flag' - Subject > 'Unsynchronisation') because they follow the frame header and > technically they are part of the following frame data. Ah... yes in 4.1.2 it says "If this flag is set all data from the end of this header to the end of this frame has been unsynchronised.", so I think you are right. I was confused because the data length indicator is stored as a syncsafe integer. > So I think this > would be a more adequate procedure: > > 1) read in data of [frameSize] bytes > 2) undo unsync, if unsync has been applied > 3) retrieve grouping info of the first byte, if grouping flag is set > 4) retrieve data length of the next four bytes, if compression flag is set > 5) retrieve encryption info byte, if encryption flag is set > 6) decrypt data from here, if encryption flag is set > 7) decompress, if compression flag ist set I think that is incorrect since the compression just mandates that the data length flag be set. But the data length indicator can be present even if compression is set and that would change the ordering you proposed above. > I'd like to know, where would I find the 'text encoding' description > byte in text frames? It is first byte in the actual frame payload. > Ben, to answer your question about the flag order. Whatever is most left in > > %0abc0000 %0h00kmnp > > comes first. It's Big Endian; the most significant bit is left. > That is my reading too... but everything would make far more sense if the data length indicator was read first giving something parsing the frame an idea of how big the result would be so it could allocate memory for it. Since the DLI is syncsafe it will not be affected by unsync. Then unsync can happen on the remainder of the frame data. Then decryption and uncompression. These are the stated order in the spec, but it is reversed from the order of the bitfield. Hence my confusion. I suppose the "right" answer is to dig through the code of a couple of projects that purport to implement this: - id3lib: http://sourceforge.net/projects/id3lib/ (C / C++ parser) - getid3: http://www.getid3.org/ (PHP parser) (the code in question is here: http://getid3.sourceforge.net/module.tag.id3v2.phps) I realized something new when reading the 2.4 spec and changes document again. The unsync flag in the tag header just indicates that all frames have unsync set _not_ that unsync should be applied on a tag level. In fact it seems that in 2.4 that flag can basically be ignored. Thank you for replying and helping make sense of this tangled spec. -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From ahmad at aratech.net Mon May 30 06:21:42 2005 From: ahmad at aratech.net (Ahmad Ismail) Date: Mon, 30 May 2005 06:21:42 -0700 Subject: [ID3 Dev] ID3 newbie need advice Message-ID: <429B1366.4060806@aratech.net> Hello people .. wherever you are! I am new to the coding for audio files and formats, and need your advice. I need to create a media player that can record MP3 and play them, BUT I want to add my own tags into them so only the files recorded by my media player can be played with it (so the player will check the tags if it was recorded by the same rocorder) is that possible? can I rename the extension too so that I can set it to play in my player? or MP3 is a trademark to replay the file back? Please let me know, and thank you for all the great work you doing -- Thank you; Ahmad M. Ismail Advanced Resources & Technologies +1- (604) - 315 - TECH (8324) ----------------------------------- http://www.aratech.net/ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From online at wan-hi.de Fri May 13 11:29:06 2005 From: online at wan-hi.de (Wan-Hi) Date: Fri, 13 May 2005 20:29:06 +0200 Subject: [ID3 Dev] Poll: Forum demand In-Reply-To: <87d5rv56u4.fsf@wigwam.deepwood.net> References: <4281D806.50708@wan-hi.de> <20050511134014.GA18643@ayup.limey.net> <4283F773.2000609@wan-hi.de> <20050513023147.GA26834@ayup.limey.net> <4284EB75.6000109@wan-hi.de> <87d5rv56u4.fsf@wigwam.deepwood.net> Message-ID: <4284F1F2.5040407@wan-hi.de> well, yes. but a http based forum would spare experts to get bothered by tons of newbie questions. Daniel Brockman wrote: >Wan-Hi writes: > > > >>I believe a forum would be a great help for developers who are >>interested in the ID3vX. Therefor I ask everyone to support the idea >>so the specs team considers the a forum setup. >> >> > >Correct me if I'm wrong, but isn't this mailing list exactly the kind >of forum you are describing? > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel at brockman.se Mon May 30 10:12:40 2005 From: daniel at brockman.se (Daniel Brockman) Date: Mon, 30 May 2005 19:12:40 +0200 Subject: [ID3 Dev] ID3 newbie need advice In-Reply-To: <429B42F6.6010705@aratech.net> (Ahmad Ismail's message of "Mon, 30 May 2005 09:44:38 -0700") References: <429B1366.4060806@aratech.net> <8764x07k80.fsf@wigwam.deepwood.net> <429B42F6.6010705@aratech.net> Message-ID: <87psv863jr.fsf@wigwam.deepwood.net> Ahmad Ismail writes: > Hello Dan, and thank you for responding [...] > let other players play the file, but for my media player, I only > want it to play those files that include the custom tag. I see. Yes, you could include a frame that ``tags'' MP3 files produced by your media player in such a way. For example, a `PRIV' frame could be used for this purpose. The following is an extract from the ``ID3 tag version 2.4.0 - Native Frames'' document?. 4.27. Private frame This frame is used to contain information from a software producer that its program uses and does not fit into the other frames. The frame consists of an 'Owner identifier' string and the binary data. The 'Owner identifier' is a null-terminated string with a URL [URL] containing an email address, or a link to a location where an email address can be found, that belongs to the organisation responsible for the frame. Questions regarding the frame should be sent to the indicated email address. The tag may contain more than one "PRIV" frame but only with different contents.
Owner identifier $00 The private data Footnotes: ? -- Daniel Brockman --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From online at wan-hi.de Mon May 16 08:32:09 2005 From: online at wan-hi.de (Wan-Hi) Date: Mon, 16 May 2005 17:32:09 +0200 Subject: [ID3 Dev] Calculating playback duration and bitrate Message-ID: <4288BCF9.3020209@wan-hi.de> hello again. i wonder if anyone knows a good resource where i can learn more about how to calculate playback durations and bitrates of mp3 files. i tried search machines like google, but i couldn't find out anything useful. i know the mp3 standard is not free and obtaining detailled specs from the owner (who's the owner anyway? frauenhofer or the MPEG consortium?) would be expensive. i'm doing this just for a hobby project and think that would just be overkill to get the whole specs. moreover i don't intend to read out the complete data from a file but only some specific infos. the reason why i ask you guys is because i think that some of you might have worked on that subject as well. if i comprehend correctly, calculation of playback duration and bitrate can be achieved by parsing all mp3 frame headers. but this appears to be a costy method to me. usually audio players retrieve these basic infos in less than half a second (i know, quite a non-general impression), so there seems to be a quicker way. i've went over to xiph.org and found their win32 lib quite useful for ogg vorbis files because it inherits everything to obtain information from an audio file. is there something similar for mp3? the ms windows media format sdk does do the things i'm interested in, but it has some disadvantages that bother me. wan-hi --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From ahmad at aratech.net Mon May 30 09:44:38 2005 From: ahmad at aratech.net (Ahmad Ismail) Date: Mon, 30 May 2005 09:44:38 -0700 Subject: [ID3 Dev] ID3 newbie need advice In-Reply-To: <8764x07k80.fsf@wigwam.deepwood.net> References: <429B1366.4060806@aratech.net> <8764x07k80.fsf@wigwam.deepwood.net> Message-ID: <429B42F6.6010705@aratech.net> Hello Dan, and thank you for responding maybe I wasnt clear on what I meant. let other players play the file, but for my media player, I only want it to play those files that include the custom tag. of course if I changed the extension of the files some players might not know its MP3, but that would be stupid really! cuz then anyone can change the extension and play them. Daniel Brockman wrote: >Hi Ahmad, > >Ahmad Ismail writes: > > > >>I need to create a media player that can record MP3 and play them, >>BUT I want to add my own tags into them so only the files recorded >>by my media player can be played with it (so the player will check >>the tags if it was recorded by the same rocorder) >> >> > >If you don't mind my asking, why are you trying to do this? > > > >>is that possible? can I rename the extension too so that I can set >>it to play in my player? or MP3 is a trademark to replay the >>file back? >> >> > >Are you saying that you want no other MP3 player to be able to play >the files? Again, I'm curious as to why you want to do this. > > > -- Thank you; Ahmad M. Ismail Advanced Resources & Technologies +1- (604) - 315 - TECH (8324) ----------------------------------- http://www.aratech.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ygor at comcast.net Sun May 15 16:48:43 2005 From: ygor at comcast.net (Dan White) Date: Sun, 15 May 2005 19:48:43 -0400 Subject: [ID3 Dev] Is there a tag that specifies a "Chapter stop" ? In-Reply-To: <3273f282aac907d54cd174590d9f9f79@comcast.net> References: <3273f282aac907d54cd174590d9f9f79@comcast.net> Message-ID: I am trying to create my own audio-book files in the style of Audible.com Is there a tag that "marks" locations downstream in the audio ? --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From online at wan-hi.de Thu May 12 17:40:19 2005 From: online at wan-hi.de (Wan-Hi) Date: Fri, 13 May 2005 02:40:19 +0200 Subject: [ID3 Dev] question about compressed unsynchronized frames In-Reply-To: <20050511134014.GA18643@ayup.limey.net> References: <4281D806.50708@wan-hi.de> <20050511134014.GA18643@ayup.limey.net> Message-ID: <4283F773.2000609@wan-hi.de> Hello. Thanks, that was helpful. The 2v4.0 specs confused me a little. But in my opinion you are wrong when saying that frame information fields are not unsynced. 4.1 says that additional frame information fields are inserted between the frame header and the actual frame data. These fields are not subject to encryption or compression. However, they are subject to unsynchronisation (4.1.2 'Frame Format Flag' - Subject 'Unsynchronisation') because they follow the frame header and technically they are part of the following frame data. So I think this would be a more adequate procedure: 1) read in data of [frameSize] bytes 2) undo unsync, if unsync has been applied 3) retrieve grouping info of the first byte, if grouping flag is set 4) retrieve data length of the next four bytes, if compression flag is set 5) retrieve encryption info byte, if encryption flag is set 6) decrypt data from here, if encryption flag is set 7) decompress, if compression flag ist set I'd like to know, where would I find the 'text encoding' description byte in text frames? Ben, to answer your question about the flag order. Whatever is most left in %0abc0000 %0h00kmnp comes first. It's Big Endian; the most significant bit is left. Thanks. Wan-Hi Ben Bennett wrote: >[Apologies for the last partial message... my fingers got confused and >sent rather than saved. (The Shame!)] > >The date_length_indicator is not appended to the frame data, it comes >before the frame data. (It follows the frame header but preceeds the >data). > >Also these bytes indicated by the frame header flags are not subject >to unsync, encryption or compression (section 4.1: These additions >affects the 'frame size' field, but are not subject to encryption or >compression.) But since only the data_length_indicator is specified >as being syncsafe there could be sync problems with the grouping byte >and the encryption byte. > >Also note that in section 4.1 it says "This information is added after >the frame header and before the frame data in the same order as the >flags that indicates them. I.e. the four bytes of decompressed size >will precede the encryption method byte." However in the flag order >below the data length indicator seems to follow the encryption flag. >Unles I am misunderstanding how they are numbering the flag bits, but >since the spec gave them letters I assume the ordering is correct. >PLEASE tell me if I have the bit ordering backwards here, the spec >(section 2) says "The most significant bit (MSB) of a byte is called >'bit 7' and the least significant bit (LSB) is called 'bit 0'.", but >then doesn't discuss how it descrives bit fields (i.e. whether bit 0 >is on the right or left of the string). > >This is how I parse a 2.4.0 frame: > 1) Read the frame header > 2) Read the flag data bytes if the flags are set: > A) Grouping identity (1 byte) > B) Encryption (1 byte) > C) Data length indicator (4 bytes) > 3) Read the remaining frame data (i.e. the size given - the flag data > size) > 4) Transform the frame data read in step 3 in the following order (if > the flag indicating that transformation is set): > A) Remove unsynchronisation > B) Decrypt > C) Uncompress > >Then you can do whatever you need to do to handle the frame data. > >Of course, I would recommend not writing 2.4 since Apple appears to >have messed up their writer and do not write the frame size as an >unsynchronised integer whereas other conforming applications do. >Also Apple appears to write the flag fields in a 2.4 frame in 2.3 >format AUGH. :-( > >I handle this by checking the flag fields to see if the high bit is >set and falling back to the 2.3 format if it is. Similarly in the >un-unsynchronisation code I check to see if the high bit is set on any >of the bytes and if it is I treat it as if it is already >un-unsynchronised. > > -ben > >On Wed, May 11, 2005 at 12:01:42PM +0200, Wan-Hi wrote: > > >>hello. >> >>can anyone tell me how a compressed and synchronized frame is intended >>to get processed? if i understand the v4.0 informal standard correctly, >>the size noted in the frame header includes the syncsafe 32bit integer >>appended to the frame content. so this is what i would do: >> >>1) read the frame header >>2) if the unsync flag is set, i undo unsync the content of the next >>'size' bytes ( which should include 32bit syncsafe data length indicator >>int) >>3) decompress the resynced content without the last 32 bits. >>4) look up the first byte of the decompressed data, to see if the >>content is ascii or unicode (if i know before that it's a text document) >> >>is this the right way to deal with compressed frames? i'd appreciate any >>help. >> >>thx. >> >>wan-hi >> >> >>--------------------------------------------------------------------- >>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 fiji at ayup.limey.net Fri May 13 17:05:11 2005 From: fiji at ayup.limey.net (Ben Bennett) Date: Fri, 13 May 2005 20:05:11 -0400 Subject: [ID3 Dev] Poll: Forum demand In-Reply-To: <8764xn54of.fsf@wigwam.deepwood.net> References: <4281D806.50708@wan-hi.de> <20050511134014.GA18643@ayup.limey.net> <4283F773.2000609@wan-hi.de> <20050513023147.GA26834@ayup.limey.net> <4284EB75.6000109@wan-hi.de> <87d5rv56u4.fsf@wigwam.deepwood.net> <4284F1F2.5040407@wan-hi.de> <4284F5FA.3010202@northpb.com> <8764xn54of.fsf@wigwam.deepwood.net> Message-ID: <20050514000511.GA20570@ayup.limey.net> On Fri, May 13, 2005 at 09:03:44PM +0200, Daniel Brockman wrote: > Dan O'Neill writes: > > I don't think that's necessary, considering the relatively low volume ... > That would be nice. It would be good to have this list in Gmane, too. > > I second both points! Out of curioisity, how many people are on this list? -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From daniel at brockman.se Fri May 13 12:03:44 2005 From: daniel at brockman.se (Daniel Brockman) Date: Fri, 13 May 2005 21:03:44 +0200 Subject: [ID3 Dev] Poll: Forum demand In-Reply-To: <4284F5FA.3010202@northpb.com> (Dan O'Neill's message of "Fri, 13 May 2005 11:46:18 -0700") References: <4281D806.50708@wan-hi.de> <20050511134014.GA18643@ayup.limey.net> <4283F773.2000609@wan-hi.de> <20050513023147.GA26834@ayup.limey.net> <4284EB75.6000109@wan-hi.de> <87d5rv56u4.fsf@wigwam.deepwood.net> <4284F1F2.5040407@wan-hi.de> <4284F5FA.3010202@northpb.com> Message-ID: <8764xn54of.fsf@wigwam.deepwood.net> Dan O'Neill writes: > Wan-Hi wrote: > >> well, yes. but a http based forum would spare experts to get >> bothered by tons of newbie questions. > > Would you like me to setup a second mailing list, ala, > id3-users at id3.org for that audience? I don't think that's necessary, considering the relatively low volume of this list. And what will become of this list once the `users' list is set up? A place to discuss future versions of ID3? > Would you like to have the id3v2 at id3.org list archived and available > in digest form via http? Note: old digests have been lost to time > and transition, sorry. That would be nice. It would be good to have this list in Gmane, too. -- Daniel Brockman --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From id3v2 at northpb.com Fri May 13 11:46:18 2005 From: id3v2 at northpb.com (Dan O'Neill) Date: Fri, 13 May 2005 11:46:18 -0700 Subject: [ID3 Dev] Poll: Forum demand In-Reply-To: <4284F1F2.5040407@wan-hi.de> References: <4281D806.50708@wan-hi.de> <20050511134014.GA18643@ayup.limey.net> <4283F773.2000609@wan-hi.de> <20050513023147.GA26834@ayup.limey.net> <4284EB75.6000109@wan-hi.de> <87d5rv56u4.fsf@wigwam.deepwood.net> <4284F1F2.5040407@wan-hi.de> Message-ID: <4284F5FA.3010202@northpb.com> Wan-Hi wrote: > well, yes. but a http based forum would spare experts to get bothered by > tons of newbie questions. Would you like me to setup a second mailing list, ala, id3-users at id3.org for that audience? Would you like to have the id3v2 at id3.org list archived and available in digest form via http? Note: old digests have been lost to time and transition, sorry. A forum is fine too, let me know what you'd like and I'll put it together. I manage the id3.org host. dano --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From online at wan-hi.de Fri May 13 11:01:25 2005 From: online at wan-hi.de (Wan-Hi) Date: Fri, 13 May 2005 20:01:25 +0200 Subject: [ID3 Dev] Poll: Forum demand In-Reply-To: <20050513023147.GA26834@ayup.limey.net> References: <4281D806.50708@wan-hi.de> <20050511134014.GA18643@ayup.limey.net> <4283F773.2000609@wan-hi.de> <20050513023147.GA26834@ayup.limey.net> Message-ID: <4284EB75.6000109@wan-hi.de> Hello. I believe a forum would be a great help for developers who are interested in the ID3vX. Therefor I ask everyone to support the idea so the specs team considers the a forum setup. If you find the idea useful send Martin Nilsson an e-mail please. Thanks. Wan-Hi Ben Bennett wrote: >[I have cc'ed info at getid3.org to try to get them to weigh in on >interpreting the 2.4 spec since they seem to have a robust parser] > >On Fri, May 13, 2005 at 02:40:19AM +0200, Wan-Hi wrote: > > >>But in my opinion you are wrong when saying that frame information >>fields are not unsynced. 4.1 says that additional frame information >>fields are inserted between the frame header and the actual frame data. >>These fields are not subject to encryption or compression. However, they >>are subject to unsynchronisation (4.1.2 'Frame Format Flag' - Subject >>'Unsynchronisation') because they follow the frame header and >>technically they are part of the following frame data. >> >> > >Ah... yes in 4.1.2 it says "If this flag is set all data from the end >of this header to the end of this frame has been unsynchronised.", so >I think you are right. I was confused because the data length >indicator is stored as a syncsafe integer. > > > >>So I think this >>would be a more adequate procedure: >> >>1) read in data of [frameSize] bytes >>2) undo unsync, if unsync has been applied >>3) retrieve grouping info of the first byte, if grouping flag is set >>4) retrieve data length of the next four bytes, if compression flag is set >>5) retrieve encryption info byte, if encryption flag is set >>6) decrypt data from here, if encryption flag is set >>7) decompress, if compression flag ist set >> >> > >I think that is incorrect since the compression just mandates that the >data length flag be set. But the data length indicator can be present >even if compression is set and that would change the ordering you >proposed above. > > > >>I'd like to know, where would I find the 'text encoding' description >>byte in text frames? >> >> > >It is first byte in the actual frame payload. > > > >>Ben, to answer your question about the flag order. Whatever is most left in >> >>%0abc0000 %0h00kmnp >> >>comes first. It's Big Endian; the most significant bit is left. >> >> >> > >That is my reading too... but everything would make far more sense if >the data length indicator was read first giving something parsing the >frame an idea of how big the result would be so it could allocate >memory for it. Since the DLI is syncsafe it will not be affected by >unsync. Then unsync can happen on the remainder of the frame data. >Then decryption and uncompression. These are the stated order in the >spec, but it is reversed from the order of the bitfield. Hence my >confusion. > >I suppose the "right" answer is to dig through the code of a couple of >projects that purport to implement this: > - id3lib: http://sourceforge.net/projects/id3lib/ (C / C++ parser) > - getid3: http://www.getid3.org/ (PHP parser) > (the code in question is here: > http://getid3.sourceforge.net/module.tag.id3v2.phps) > > >I realized something new when reading the 2.4 spec and changes >document again. The unsync flag in the tag header just indicates that >all frames have unsync set _not_ that unsync should be applied on a >tag level. In fact it seems that in 2.4 that flag can basically be >ignored. > > >Thank you for replying and helping make sense of this tangled spec. > > -ben > >--------------------------------------------------------------------- >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 fiji at ayup.limey.net Wed May 11 04:29:04 2005 From: fiji at ayup.limey.net (Ben Bennett) Date: Wed, 11 May 2005 07:29:04 -0400 Subject: [ID3 Dev] question about compressed unsynchronized frames In-Reply-To: <4281D806.50708@wan-hi.de> References: <4281D806.50708@wan-hi.de> Message-ID: <20050511112904.GA15568@ayup.limey.net> Yes the field size includes any bytes added to support the frame header flags (group id and data length). I think your processing makes sense. I am not sure why the data_length_indicator is syncsafe since compression follows -ben On Wed, May 11, 2005 at 12:01:42PM +0200, Wan-Hi wrote: > hello. > > can anyone tell me how a compressed and synchronized frame is intended > to get processed? if i understand the v4.0 informal standard correctly, > the size noted in the frame header includes the syncsafe 32bit integer > appended to the frame content. so this is what i would do: > > 1) read the frame header > 2) if the unsync flag is set, i undo unsync the content of the next > 'size' bytes ( which should include 32bit syncsafe data length indicator > int) > 3) decompress the resynced content without the last 32 bits. > 4) look up the first byte of the decompressed data, to see if the > content is ascii or unicode (if i know before that it's a text document) > > is this the right way to deal with compressed frames? i'd appreciate any > help. > > thx. > > wan-hi > > > --------------------------------------------------------------------- > 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 daniel at brockman.se Mon May 16 01:03:33 2005 From: daniel at brockman.se (Daniel Brockman) Date: Mon, 16 May 2005 10:03:33 +0200 Subject: [ID3 Dev] ID3v2 Text Encoding and VC++ In-Reply-To: <4287DEB3.9050802@wan-hi.de> (Wan-Hi's message of "Mon, 16 May 2005 01:43:47 +0200") References: <4287DEB3.9050802@wan-hi.de> Message-ID: <87r7g7oawa.fsf@wigwam.deepwood.net> Wan-Hi writes: > does anyone know if the mfc support all unicode variants? i searched through > the msdn library but couldn't find out more than the fact that the mfc do > support unicode through wchar (16bit). but does this include utf-16 and > utf-16be as well? and what about utf-8? the problem is, i'd like to wrap the > id3v2 text frame content by a cstring object, but it accepts char and > wchar only. Hi Wan-Hi, I don't know about UTF-8, but if they claim to support Unicode and the API says it accepts wchar_t, that means UTF-16 should work. Regarding endianness, the string class should be able to figure that out and deal with it correctly due to the byte-order mark, which ID3v2 requires all UTF-16 strings to start with. Just try it and see what happens. :-) -- Daniel Brockman --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From daniel at brockman.se Fri May 13 14:04:40 2005 From: daniel at brockman.se (Daniel Brockman) Date: Fri, 13 May 2005 23:04:40 +0200 Subject: [ID3 Dev] Poll: Forum demand In-Reply-To: <42850752.1000807@wan-hi.de> (Wan-Hi's message of "Fri, 13 May 2005 22:00:18 +0200") References: <4281D806.50708@wan-hi.de> <20050511134014.GA18643@ayup.limey.net> <4283F773.2000609@wan-hi.de> <20050513023147.GA26834@ayup.limey.net> <4284EB75.6000109@wan-hi.de> <87d5rv56u4.fsf@wigwam.deepwood.net> <4284F1F2.5040407@wan-hi.de> <4284F5FA.3010202@northpb.com> <42850752.1000807@wan-hi.de> Message-ID: <87wtq24z2v.fsf@wigwam.deepwood.net> Wan-Hi writes: > I second the idea of making the list available via http. I'd also > prefer a forum because it would be easier to search for similar > problems discussed in the past What makes you think that it won't be easy to search through the mailing list archive? > and to sort out uninteresting topics (from a vet's point of view) Mail clients have been able to do this for a very long time. > Moreover, personally, I would get a chance to deal with my unsolved > problems while not at home because I don't use a mobile e-mail > client. But that's just my personal taste. Personally, I can't be bothered to deal with clunky web-based forums. But that's just my personal taste. -- Daniel Brockman --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From daniel at brockman.se Fri May 13 11:17:07 2005 From: daniel at brockman.se (Daniel Brockman) Date: Fri, 13 May 2005 20:17:07 +0200 Subject: [ID3 Dev] Poll: Forum demand In-Reply-To: <4284EB75.6000109@wan-hi.de> (Wan-Hi's message of "Fri, 13 May 2005 20:01:25 +0200") References: <4281D806.50708@wan-hi.de> <20050511134014.GA18643@ayup.limey.net> <4283F773.2000609@wan-hi.de> <20050513023147.GA26834@ayup.limey.net> <4284EB75.6000109@wan-hi.de> Message-ID: <87d5rv56u4.fsf@wigwam.deepwood.net> Wan-Hi writes: > I believe a forum would be a great help for developers who are > interested in the ID3vX. Therefor I ask everyone to support the idea > so the specs team considers the a forum setup. Correct me if I'm wrong, but isn't this mailing list exactly the kind of forum you are describing? -- Daniel Brockman --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From online at wan-hi.de Wed May 11 03:01:42 2005 From: online at wan-hi.de (Wan-Hi) Date: Wed, 11 May 2005 12:01:42 +0200 Subject: [ID3 Dev] question about compressed unsynchronized frames Message-ID: <4281D806.50708@wan-hi.de> hello. can anyone tell me how a compressed and synchronized frame is intended to get processed? if i understand the v4.0 informal standard correctly, the size noted in the frame header includes the syncsafe 32bit integer appended to the frame content. so this is what i would do: 1) read the frame header 2) if the unsync flag is set, i undo unsync the content of the next 'size' bytes ( which should include 32bit syncsafe data length indicator int) 3) decompress the resynced content without the last 32 bits. 4) look up the first byte of the decompressed data, to see if the content is ascii or unicode (if i know before that it's a text document) is this the right way to deal with compressed frames? i'd appreciate any help. thx. wan-hi --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From online at wan-hi.de Fri May 13 13:00:18 2005 From: online at wan-hi.de (Wan-Hi) Date: Fri, 13 May 2005 22:00:18 +0200 Subject: [ID3 Dev] Poll: Forum demand In-Reply-To: <4284F5FA.3010202@northpb.com> References: <4281D806.50708@wan-hi.de> <20050511134014.GA18643@ayup.limey.net> <4283F773.2000609@wan-hi.de> <20050513023147.GA26834@ayup.limey.net> <4284EB75.6000109@wan-hi.de> <87d5rv56u4.fsf@wigwam.deepwood.net> <4284F1F2.5040407@wan-hi.de> <4284F5FA.3010202@northpb.com> Message-ID: <42850752.1000807@wan-hi.de> Dan O'Neill wrote: > Wan-Hi wrote: > >> well, yes. but a http based forum would spare experts to get bothered >> by tons of newbie questions. > > > Would you like me to setup a second mailing list, ala, > id3-users at id3.org for that audience? > > Would you like to have the id3v2 at id3.org list archived and available > in digest form via http? Note: old digests have been lost to time and > transition, sorry. > > A forum is fine too, let me know what you'd like and I'll put it > together. I manage the id3.org host. > > dano > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org I second the idea of making the list available via http. I'd also prefer a forum because it would be easier to search for similar problems discussed in the past and to sort out uninteresting topics (from a vet's point of view). Moreover, personally, I would get a chance to deal with my unsolved problems while not at home because I don't use a mobile e-mail client. But that's just my personal taste. Thanks. Wan-Hi --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From fiji at ayup.limey.net Wed May 11 06:40:14 2005 From: fiji at ayup.limey.net (Ben Bennett) Date: Wed, 11 May 2005 09:40:14 -0400 Subject: [ID3 Dev] question about compressed unsynchronized frames In-Reply-To: <4281D806.50708@wan-hi.de> References: <4281D806.50708@wan-hi.de> Message-ID: <20050511134014.GA18643@ayup.limey.net> [Apologies for the last partial message... my fingers got confused and sent rather than saved. (The Shame!)] The date_length_indicator is not appended to the frame data, it comes before the frame data. (It follows the frame header but preceeds the data). Also these bytes indicated by the frame header flags are not subject to unsync, encryption or compression (section 4.1: These additions affects the 'frame size' field, but are not subject to encryption or compression.) But since only the data_length_indicator is specified as being syncsafe there could be sync problems with the grouping byte and the encryption byte. Also note that in section 4.1 it says "This information is added after the frame header and before the frame data in the same order as the flags that indicates them. I.e. the four bytes of decompressed size will precede the encryption method byte." However in the flag order below the data length indicator seems to follow the encryption flag. Unles I am misunderstanding how they are numbering the flag bits, but since the spec gave them letters I assume the ordering is correct. PLEASE tell me if I have the bit ordering backwards here, the spec (section 2) says "The most significant bit (MSB) of a byte is called 'bit 7' and the least significant bit (LSB) is called 'bit 0'.", but then doesn't discuss how it descrives bit fields (i.e. whether bit 0 is on the right or left of the string). This is how I parse a 2.4.0 frame: 1) Read the frame header 2) Read the flag data bytes if the flags are set: A) Grouping identity (1 byte) B) Encryption (1 byte) C) Data length indicator (4 bytes) 3) Read the remaining frame data (i.e. the size given - the flag data size) 4) Transform the frame data read in step 3 in the following order (if the flag indicating that transformation is set): A) Remove unsynchronisation B) Decrypt C) Uncompress Then you can do whatever you need to do to handle the frame data. Of course, I would recommend not writing 2.4 since Apple appears to have messed up their writer and do not write the frame size as an unsynchronised integer whereas other conforming applications do. Also Apple appears to write the flag fields in a 2.4 frame in 2.3 format AUGH. :-( I handle this by checking the flag fields to see if the high bit is set and falling back to the 2.3 format if it is. Similarly in the un-unsynchronisation code I check to see if the high bit is set on any of the bytes and if it is I treat it as if it is already un-unsynchronised. -ben On Wed, May 11, 2005 at 12:01:42PM +0200, Wan-Hi wrote: > hello. > > can anyone tell me how a compressed and synchronized frame is intended > to get processed? if i understand the v4.0 informal standard correctly, > the size noted in the frame header includes the syncsafe 32bit integer > appended to the frame content. so this is what i would do: > > 1) read the frame header > 2) if the unsync flag is set, i undo unsync the content of the next > 'size' bytes ( which should include 32bit syncsafe data length indicator > int) > 3) decompress the resynced content without the last 32 bits. > 4) look up the first byte of the decompressed data, to see if the > content is ascii or unicode (if i know before that it's a text document) > > is this the right way to deal with compressed frames? i'd appreciate any > help. > > thx. > > wan-hi > > > --------------------------------------------------------------------- > 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 daniel at brockman.se Mon May 30 09:27:11 2005 From: daniel at brockman.se (Daniel Brockman) Date: Mon, 30 May 2005 18:27:11 +0200 Subject: [ID3 Dev] ID3 newbie need advice In-Reply-To: <429B1366.4060806@aratech.net> (Ahmad Ismail's message of "Mon, 30 May 2005 06:21:42 -0700") References: <429B1366.4060806@aratech.net> Message-ID: <8764x07k80.fsf@wigwam.deepwood.net> Hi Ahmad, Ahmad Ismail writes: > I need to create a media player that can record MP3 and play them, > BUT I want to add my own tags into them so only the files recorded > by my media player can be played with it (so the player will check > the tags if it was recorded by the same rocorder) If you don't mind my asking, why are you trying to do this? > is that possible? can I rename the extension too so that I can set > it to play in my player? or MP3 is a trademark to replay the > file back? Are you saying that you want no other MP3 player to be able to play the files? Again, I'm curious as to why you want to do this. -- Daniel Brockman --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org