From chris.newell at rd.bbc.co.uk Tue Oct 25 04:02:56 2005 From: chris.newell at rd.bbc.co.uk (Chris Newell) Date: Tue, 25 Oct 2005 12:02:56 +0100 Subject: [ID3 Dev] Revised chapter frame proposal Message-ID: <6.1.2.0.2.20051021121439.02d75ac8@pop3> Colleagues, Please find attached a third revision of the Chapter frame proposal. It incorporates some changes requested on the reflector over the last week and some clarifications. In summary: (1) The child elements of a CTOC can now be a combination of CTOC and CHAP frames, rather than one or the other. As a result, the Child Element Type flag has been removed. (2) The semantics of the Top-level flag have been changed so that it now identifies a single, unique CTOC which is the root of the Table of Contents tree. (3) Added text to explain that the Element ID should not be used as a human readable identifier. (4) Added a recommendation that CTOC and CHAP frames should include a TIT2 sub-frame to provide a human readable identifier. If you have any further comments please let me know. Hopefully, we're getting close to finalization. Chris -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: id3v2_chapters_rev3.txt URL: -------------- next part -------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr J.C. Newell Digital Media Group, BBC Research & Development Kingswood Warren, Woodland Way, Tadworth, Surrey KT20 6NP UK mailto:chris.newell at rd.bbc.co.uk http://www.bbc.co.uk/rd Tel: +44 (0)1737 839659 Switchboard: +44 1737 839500 Fax: +44 (0)1737 839665 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -------------- next part -------------- --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From pschmitz at yahoo-inc.com Thu Oct 13 16:53:08 2005 From: pschmitz at yahoo-inc.com (Patrick Schmitz) Date: Thu, 13 Oct 2005 16:53:08 -0700 Subject: [ID3 Dev] ID3 chapter tags feedback Message-ID: <200510132351.j9DNpuxY082635@mrout1-b.corp.dcn.yahoo.com> Hi - I am new to this list, having just heard about the chapter tags work. I am a researcher at Yahoo Berkeley, working on annotation of time based media, and so we are naturally interested in the work going on with Chapter tagging of MP3 content. My colleagues and I went through the docs today, and our first impression is that we like much of what we see. We have a couple of clarifying questions, and some suggestions. I am no expert on MP3 "syntax" and header constraints, so forgive me if I make some silly suggestions that are not in the spirit of MP3. My background is with XML formats, and especially SMIL [*]. As such, I was translating in my head from the descriptions I read to how I think about descriptions for timing. I hope this is useful both from the perspective of clarifying the semantics as expressed in your docs, and as an introduction to producing a description of an XML schema that would parallel your work (e.g., as an interchange language for tools producing ID3 Chapter frames). In SMIL timing [**], there are two common time containers: "par" (for parallel) and "seq" (for sequence or sequential). Children of par elements have timing relative to the par, but can overlap one another with few constraints. Children of a seq are defined to be a sequence, and are constrained to play one after another, possibly with delays between any two items. While SMIL is defined for synchronization, the basic concepts can be applied to this case as a description of the relationship of the chapters in a CTOC element. It looks to me like CTOC plus the "Ordered bit" in the flags is more or less equivalent to this - am I right? In the spec, the Chapter start time and end time are defined as being relative to the beginning of the file, and yet the CTOC structure implies that there is a hierarchy of chapter elements. I would think that it makes more sense to have the timing reflect the TOC structure. Thus if I have defined a major section of the file as a chapter, I can describe pieces within that section relative to the section begin, rather than from the beginning of the file. This means that start times and byte offsets must be added together to find an absolute offset into the file, but it also means that excerpting a section of the whole file is more straightforward (only the top-level offsets change). This would of course require that the CTOC elements also have timing information - does that conflict very much with your current thinking? We've been playing with some syntax to describe temporal extents in media as part of an annotation framework. We are developing the XML syntax for this now, but I can say that it borrows from SMIL timing syntax (although a good deal more constrained (simpler) than the expressivity of SMIL 2.0 Timing. We are hoping that this would meld well with the ID3 chapter tags work, allowing us a means of encapsulating our semantics in an MP3 file. Have you done anything yet in the area of an XML syntax for the ID3 chapter tags? We'd be happy to contribute to such an effort. Thanks - Patrick [*] SMIL 2.0 at W3C: http://www.w3.org/TR/2005/REC-SMIL2-20050107/ [**] SMIL 2.0 time containers: http://www.w3.org/TR/2005/REC-SMIL2-20050107/smil-timing.html#Timing-TimeCon tainerSyntax -------------- next part -------------- An HTML attachment was scrubbed... URL: From chris.newell at rd.bbc.co.uk Wed Oct 12 03:51:05 2005 From: chris.newell at rd.bbc.co.uk (Chris Newell) Date: Wed, 12 Oct 2005 11:51:05 +0100 Subject: [ID3 Dev] Chapter frame API Message-ID: <6.1.2.0.2.20051012113938.030a7af0@pop3> Hi, For anyone who may want to experiment with the proposed ID3v2 chapter frames I've documented the Java API used by my Chapter authoring tool. This API is built on top of the ID3 API developed by Jens Vonderheide and provides classes to create or decode CHAP & CTOC frames. There are also some utility classes for Text, URL and APIC frames. The javadoc is available at: http://id3v2-chap-tool.sourceforge.net/javadoc/index.html And the source is available at: http://cvs.sourceforge.net/viewcvs.py/id3v2-chap-tool/ID3v2ChapterTool/src Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr J.C. Newell Digital Media Group, BBC Research & Development Kingswood Warren, Woodland Way, Tadworth, Surrey KT20 6NP UK mailto:chris.newell at rd.bbc.co.uk http://www.bbc.co.uk/rd Tel: +44 (0)1737 839659 Switchboard: +44 1737 839500 Fax: +44 (0)1737 839665 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From deathboy2000 at earthlink.net Mon Oct 31 06:07:24 2005 From: deathboy2000 at earthlink.net (darien) Date: Mon, 31 Oct 2005 07:07:24 -0700 Subject: [ID3 Dev] questions regarding TBPM frame. In-Reply-To: References: <6.2.5.6.0.20051030223858.02ecdb90@earthlink.net> Message-ID: <6.2.5.6.0.20051031034035.02e9f310@earthlink.net> hey there Pyt ... thanks for replying. >Strictly speaking, TBPM is a text frame, so it is very possible for >it to be set to just about anything textual if a program would allow >it. However, the v2.4 spec is pretty clear that it is an integer and >that it is beats per minute, so you cannot set it to 123.45, and >even though you could set it to 12345, but that would probably >meaningless from a musical standpoint... > >I guess your programmer must have decided that more than 999 beats >per minute is nonsense, which can be understood but is indeed going >a bit further than the spec intends. > >Not sure this helps... it sort of does ... it's brought a couple of things to light, and i have a question... how does one go about getting the spec for the TBPM frame changed to allow for a decimal place and 'non-whole' bpm measurements (ie 132.68, 95.35, etc) as allowable and legitimate data for the spec? i feel that it's not right the way it is, i can think of quite a few arguments for why the 'standard' should be changed to allow a decimal place if desired or needed, and i'd like to push to have it changed. it would make my life a bit easier in a few different ways, and i reckon it would probably help other people out there as well. bpm measurement is *never* a solid, honest-to-goodness integer. well, not practically, anyway. it's usually measured in averages, because there are no recordings out there that are perfectly on-beat from start to finish ... there are many obvious reasons why... neither midi clocks nor human drummers are ever 100% on the money with regard to keeping time, hence having bpm measurements of 132.68, 95.35, etc. while midi clocks come close, there's always a little bit of slide with regard to the accuracy of its' generation. human drummers are never 100% -- every human drummer is always off the mark by some percentage (usually depending on how drunk they are). the only thing that is pretty much right-on is smpte, and a large percentage of professional musicians don't use smpte for clock generation (though there are a few out there that do, especially if they're working in hollywood on film or television projects). most software applications that measure bpm properly do not end up with a bpm measurement that is a whole integer either (here's one i know of that's free and writes the value into the id3v2.x tag : http://www.mixmeister.com/download_freestuff.html ) ... i'm a dance music dj and i play a lot of electronically-based music. i play house, prog house, hip hop, breaks, and i play some mobile dj gigs too if the money's right. years ago, i used to exclusively dj with vinyl records and cd's, but now i use traktor dj studio to dj with. traktor dj studio has the ability to be able to control/manipulate playback of mp3's using a special hardware audio interface and vinyl records with a recording of timecode cut onto them. the timecode records tell the computer what pitch the record is playing back at, where the needle is on the record and so forth. the records and hardware are essentially a control interface, and a brilliant one at that. about 80% of the mp3's i generate to dj with are from recordings of vinyl records, because that's the medium of choice for dj'ing electronic music -- a lot of prime stuff gets released on vinyl that never sees a digital release, even in this digital world of ours. vinyl, as a rule, is an imperfect medium, which opens up a pretty huge can o' worms in itself with regard to bpm and speed in general. here are some examples of things that cause timing issues with vinyl records: o - vinyl records are never perfectly flat. every record pressed (even a 180 gram audiophile grade record) has a certain degree of warp to it. they can be really close to flat, but never perfectly flat o - the stamper plates used to press records are made of nickel, and a high amount of pressure is placed on them for every record pressed -- it takes 120 tons of pressure to press a vinyl record. as a result, every pressing degrades the stampers slightly. stampers are only good for 1000 pressings. after that, the stampers will have degraded enough to create a noticably imperfect product and a new set of stampers must be used. o - consistency of the vinyl material differs slightly from batch to batch couple these factors with a midi clock that doesn't generate time perfectly and you've got a recording that isn't going to be anywhere near perfect, timing and bpm measurement-wise. this is just one example. another that i could explore is disco or funk tracks from the 70's... parliament, the bee gee's, gloria gaynor, cheryl lynn, donna summer, etc. all of that stuff was recorded onto analog tape, and human drummers were employed. analog tape stretches and shrinks with temperature and general use. tape machines of the day weren't digitally regulated, and no analog motor is perfect. pair those imperfections with a human drummer and loads of disco or funk swing, and you've got a recording that isn't anywhere near a whole integer bpm-wise. so yeah ... some good arguments there. ;) any advice on how to go about getting the spec changed for the TBPM field would be greatly appreciated. cheers. --darien! --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From kirkm at xtra.co.nz Wed Oct 26 18:26:04 2005 From: kirkm at xtra.co.nz (Kirk McMillan) Date: Thu, 27 Oct 2005 14:26:04 +1300 Subject: [ID3 Dev] Info Sought In-Reply-To: <4da424620510260611k7eef734o6df98094133c5359@mail.gmail.com> References: <435EF348.9060809@xtra.co.nz> <4da424620510260611k7eef734o6df98094133c5359@mail.gmail.com> Message-ID: <43602CAC.40708@xtra.co.nz> Thank you Tom. As yet no VB library has been found, I know one other person who's also been looking. I'm working at a fairly basic level, if Winamp can correctly read the tags I create, it's mission over. I'm only using the more common frames (at this stage, anyway) You may be right and some of the issues are a version differences. My main reference is id3.org/id3v2.4.0-structure.txt. Cheers - Kirk Tom Sorensen wrote: >I highly recommend finding an ID3 library for VB and using that. >Writing your own is certainly doable, but there are a lot of nuances >in the tag format, and if you get them wrong then other programs may >have problems reading your files. > >As far as Winamp goes -- it produces clean tags, but realize that they >are ID3v2.3 tags, not 2.4. Make sure you're looking at the right >version of the standard. It also uses an expanded list of ID3v1 >genres, so that's something to be aware of as well. > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From id3v2 at northpb.com Wed Oct 26 17:16:57 2005 From: id3v2 at northpb.com (Dan O'Neill) Date: Wed, 26 Oct 2005 17:16:57 -0700 Subject: [ID3 Dev] Implementation page updates Message-ID: <43601C79.9020000@northpb.com> AudioTT (audio tagging tool) http://www.audiott.com/ has been added to the implementations page http://id3.org/implement.html AudioTT (ATT) is FREEWARE Audio Tagging Tool. It means that this application allows user to edit ID3 tags of MP3 files. If you don't know what ID3 tags are, first check out www.id3.org. ATT supports both ID3v1 and ID3v2 tag editing in very smart way. Using this application you are able to edit your whole MP3 collection just by few mouse clicks. Please send any change requests for the web site to id3v2 at id3.org and I'll make them. Thank you, dan --------------------------------------------------------------------- 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 Oct 19 18:32:44 2005 From: fiji at ayup.limey.net (Ben Bennett) Date: Wed, 19 Oct 2005 21:32:44 -0400 Subject: [ID3 Dev] Update on ID3 Chapter tag publication efforts In-Reply-To: <4356D5B6.4060709@northpb.com> References: <4356D5B6.4060709@northpb.com> Message-ID: <20051020013244.GA3665@ayup.limey.net> If we are updating the ID3.org website can we put a clarification out saying that ID3v2.4 frame sizes are SYNCSAFE. Certain popular programs (iTunes, and others) do not do that. Of course since they have so messed up people's tags and there will be no way to untangle them perhaps a new version (2.5 or 2.4.1) would make sense? -ben --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From chris.newell at rd.bbc.co.uk Wed Oct 19 04:02:48 2005 From: chris.newell at rd.bbc.co.uk (Chris Newell) Date: Wed, 19 Oct 2005 12:02:48 +0100 Subject: [ID3 Dev] ID3 chapter tags feedback In-Reply-To: <200510182250.j9IMov6p049035@mrout2.yahoo.com> References: <6.1.2.0.2.20051014170310.03049838@pop3> <200510182250.j9IMov6p049035@mrout2.yahoo.com> Message-ID: <6.1.2.0.2.20051019112800.02df3658@pop3> Patrick, Thanks for your analysis and comments. At 23:52 18/10/2005, you wrote: >Why do you constrain a CTOC element to only have one class of children? >I have a number of use-cases I sketched out that would be more >cumbersome with this constraint, and so I was wondering what the >rationale was. I think the original motivation was simplicity. However, if you have a use-case which requires a mixed list of child elements we should support it. Changes to the specification would be limited to the removal of the Child Element Type flag and the associated restriction. Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr J.C. Newell Digital Media Group, BBC Research & Development Kingswood Warren, Woodland Way, Tadworth, Surrey KT20 6NP UK mailto:chris.newell at rd.bbc.co.uk http://www.bbc.co.uk/rd Tel: +44 (0)1737 839659 Switchboard: +44 1737 839500 Fax: +44 (0)1737 839665 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From christophe at kualasoft.com Fri Oct 14 19:35:07 2005 From: christophe at kualasoft.com (Christophe Bouhier) Date: Sat, 15 Oct 2005 10:35:07 +0800 Subject: [ID3 Dev] Chapter frame API References: <6.1.2.0.2.20051012113938.030a7af0@pop3> Message-ID: <00f801c5d131$106b3030$3701a8c0@eapac.ericsson.se> Hi, I have committed the latest vdHeide code (With bug fixes and ID3v2.2 to ID3v2.3 conversion code) to a new sourceforge project. This is now the official home of this library. I would ask anyone interrested to contribute to send me an e-mail so I can add you to the project. Chris: Would love to have you on board to commit the CHAP & CTOC frames to the latest code base. Please note, I am doing this on request from Jens himself, as we was happy with bugfixes we committed to his code and had no time himself to work on the library. The code is GPL. The project is barebone, no javadoc, build facilities. This will be added gradually. Cheers / Christophe ----- Original Message ----- From: "Chris Newell" To: Sent: Wednesday, October 12, 2005 6:51 PM Subject: [ID3 Dev] Chapter frame API > Hi, > > For anyone who may want to experiment with the proposed ID3v2 chapter frames I've documented the Java API used by my Chapter authoring tool. This API is built on top of the ID3 API developed by Jens Vonderheide and provides classes to create or decode CHAP & CTOC frames. There are also some utility classes for Text, URL and APIC frames. > > The javadoc is available at: > > http://id3v2-chap-tool.sourceforge.net/javadoc/index.html > > And the source is available at: > > http://cvs.sourceforge.net/viewcvs.py/id3v2-chap-tool/ID3v2ChapterTool/src > > Chris > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dr J.C. Newell > Digital Media Group, BBC Research & Development > Kingswood Warren, Woodland Way, Tadworth, Surrey > KT20 6NP UK > mailto:chris.newell at rd.bbc.co.uk http://www.bbc.co.uk/rd > Tel: +44 (0)1737 839659 > Switchboard: +44 1737 839500 > Fax: +44 (0)1737 839665 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > --------------------------------------------------------------------- > 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 chris.newell at rd.bbc.co.uk Mon Oct 17 02:25:05 2005 From: chris.newell at rd.bbc.co.uk (Chris Newell) Date: Mon, 17 Oct 2005 10:25:05 +0100 Subject: [ID3 Dev] ID3 chapter tags feedback In-Reply-To: <200510132351.j9DNpuxY082635@mrout1-b.corp.dcn.yahoo.com> References: <200510132351.j9DNpuxY082635@mrout1-b.corp.dcn.yahoo.com> Message-ID: <6.1.2.0.2.20051014170310.03049838@pop3> Patrick, At 00:53 14/10/2005, you wrote: >Hi ? I am new to this list, having just heard about the chapter tags work. I am a researcher at Yahoo Berkeley, working on annotation of time based media, and so we are naturally interested in the work going on with Chapter tagging of MP3 content. > >My colleagues and I went through the docs today, and our first impression is that we like much of what we see. We have a couple of clarifying questions, and some suggestions. I am no expert on MP3 ?syntax? and header constraints, so forgive me if I make some silly suggestions that are not in the spirit of MP3. > >My background is with XML formats, and especially SMIL [*]. As such, I was translating in my head from the descriptions I read to how I think about descriptions for timing. I hope this is useful both from the perspective of clarifying the semantics as expressed in your docs, and as an introduction to producing a description of an XML schema that would parallel your work (e.g., as an interchange language for tools producing ID3 Chapter frames). > >In SMIL timing [**], there are two common time containers: ?par? (for parallel) and ?seq? (for sequence or sequential). Children of par elements have timing relative to the par, but can overlap one another with few constraints. Children of a seq are defined to be a sequence, and are constrained to play one after another, possibly with delays between any two items. While SMIL is defined for synchronization, the basic concepts can be applied to this case as a description of the relationship of the chapters in a CTOC element. It looks to me like CTOC plus the ?Ordered bit? in the flags is more or less equivalent to this ? am I right? Yes. I'm not very familiar with SMIL but this sounds like an identical concept. >In the spec, the Chapter start time and end time are defined as being relative to the beginning of the file, and yet the CTOC structure implies that there is a hierarchy of chapter elements. I would think that it makes more sense to have the timing reflect the TOC structure. Thus if I have defined a major section of the file as a chapter, I can describe pieces within that section relative to the section begin, rather than from the beginning of the file. This means that start times and byte offsets must be added together to find an absolute offset into the file, but it also means that excerpting a section of the whole file is more straightforward (only the top-level offsets change). > >This would of course require that the CTOC elements also have timing information ? does that conflict very much with your current thinking? Although I can see the advantages during editing I think we should use absolute offsets within ID3 tags as this makes life easier for media players (often low profile devices). Relative offsets would also break a useful feature of the current proposal - it's possible to refer to a CHAP frame from more than one CTOC. This allows you to provide more than one table of contents for a single file. e.g. for the recording of a rock festival you could provide: - a full, temporally ordered table of contents - a table providing an index of band names - a table listing highlights >We?ve been playing with some syntax to describe temporal extents in media as part of an annotation framework. We are developing the XML syntax for this now, but I can say that it borrows from SMIL timing syntax (although a good deal more constrained (simpler) than the expressivity of SMIL 2.0 Timing. We are hoping that this would meld well with the ID3 chapter tags work, allowing us a means of encapsulating our semantics in an MP3 file. Have you done anything yet in the area of an XML syntax for the ID3 chapter tags? We?d be happy to contribute to such an effort. The inspiration for the chapter frame proposal was an open standard for Personal Video Recorders called "TV-Anytime" (http://www.tv-anytime.org/) which I've worked on for a number of years. TV-Anytime has an XML schema which supports chapters (they call it segmentation) and this maps quite well with the binary structures used in the ID3 chapter frame proposal. Best regards, Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr J.C. Newell Digital Media Group, BBC Research & Development Kingswood Warren, Woodland Way, Tadworth, Surrey KT20 6NP UK mailto:chris.newell at rd.bbc.co.uk http://www.bbc.co.uk/rd Tel: +44 (0)1737 839659 Switchboard: +44 1737 839500 Fax: +44 (0)1737 839665 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From id3v2 at northpb.com Wed Oct 19 16:24:38 2005 From: id3v2 at northpb.com (Dan O'Neill) Date: Wed, 19 Oct 2005 16:24:38 -0700 Subject: [ID3 Dev] Update on ID3 Chapter tag publication efforts Message-ID: <4356D5B6.4060709@northpb.com> Hi everyone, The ID3 chapter tag proposal has been getting some attention from various directions over the last week and the second revision put forth looks relatively solid. The ID3.org website has been updated to put the standard out in a more public location - hope that's okay with everyone - and the home page has been updated to let people know that there's been an update. http://id3.org/develop.html now contains a section entitled "ID3 work in progress" and within that section are links to ID3 chapter proposals and block diagrams. Next Monday NetworkWorld is scheduled to publish an article that talks about ID3 and specifically the Chapter tag proposal in it's GearHead column. http://www.networkworld.com/columnists/gearhead.html Regards, Dan --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From id3v2 at northpb.com Wed Oct 26 08:21:05 2005 From: id3v2 at northpb.com (Dan O'Neill) Date: Wed, 26 Oct 2005 08:21:05 -0700 Subject: [ID3 Dev] Rev 3 of CTOC/CHAP frame standard published Message-ID: <435F9EE1.2020605@northpb.com> The developers page has been udpated to reflect revision 3 of the CTOC/CHAP frame standard. http://www.id3.org/develop.html Has anyone created an alpha version of a tag editor / player that supports CTOC and CHAP frames? dano --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From bmearns at coe.neu.edu Sat Oct 29 08:53:27 2005 From: bmearns at coe.neu.edu (Brian Mearns) Date: Sat, 29 Oct 2005 11:53:27 -0400 Subject: [ID3 Dev] Padding Size in v2.3 extended header In-Reply-To: <000801c5dc5c$f6101c00$0500000a@MARVIN> References: <4362A399.2050300@coe.neu.edu> <000801c5dc5c$f6101c00$0500000a@MARVIN> Message-ID: <43639AF7.2030205@coe.neu.edu> Great, thanks. Andy Kernahan wrote: > Brian, > > the extended header is subject to unsynchronisation (if applied), so > the padding field is not sync-safe. > > Andy. > > ----- Original Message ----- From: "Brian Mearns" > To: "Id3v2 Mailing List" > Sent: Friday, October 28, 2005 11:18 PM > Subject: [ID3 Dev] Padding Size in v2.3 extended header > > >> In ID3v2.3.0, is the Padding Size field in the ID3 Tag Extended Header >> sync-safe? >> >> Thanks. >> >> -Brian >> >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From chris.newell at rd.bbc.co.uk Thu Oct 20 07:03:19 2005 From: chris.newell at rd.bbc.co.uk (Chris Newell) Date: Thu, 20 Oct 2005 15:03:19 +0100 Subject: Fwd: RE: [ID3 Dev] ID3 chapter tags feedback Message-ID: <6.1.2.0.2.20051020093246.02e444d0@pop3> Colleagues, Recently, Patrick Schmitz requested that CHAP and CTOC frames could both appear at the same level in a Table of Contents tree. I've noticed this implies that CHAP frames could appear alongside CTOC frames at the top-level of the Table of Contents tree. Unfortunately, this raises a problem since CHAP frames do not have a Top-level flag. As a solution, I suggest we change the semantics of the Top-level flag slightly: - currently, the Top-level flag identifies one or more CTOC frames that are present at the top-level of the Table of Contents. - instead we could use it to identify a single, unique CTOC frame which represents the root of the Table of Contents. This root CTOC would list all the frames at the top-level of the Table of Contents and could now include both CTOC and CHAP frames. I think this is neater and easier to understand than the previous approach. However, if anyone has comments please let me know. Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr J.C. Newell Digital Media Group, BBC Research & Development Kingswood Warren, Woodland Way, Tadworth, Surrey KT20 6NP UK mailto:chris.newell at rd.bbc.co.uk http://www.bbc.co.uk/rd Tel: +44 (0)1737 839659 Switchboard: +44 1737 839500 Fax: +44 (0)1737 839665 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From andrew.kernahan at btinternet.com Thu Oct 27 11:22:48 2005 From: andrew.kernahan at btinternet.com (Andy Kernahan) Date: Thu, 27 Oct 2005 19:22:48 +0100 Subject: [ID3 Dev] Info Sought References: <435EF348.9060809@xtra.co.nz> <000a01c5da2e$5cb69eb0$0500000a@MARVIN> <43603072.8040002@xtra.co.nz> <4da424620510270616n21206296v6f760b7f7404132c@mail.gmail.com> Message-ID: <000a01c5db23$6f494be0$0500000a@MARVIN> Kirk, the answer to your other question is 7F 7F 7F 7F for a maximum value sync-safe integer. As the for the comment frame it has the following structure: text encoding ID (1byte), language ID (3bytes (3 ASCII chars)), description (null terminated (\0)), body of text. Below is an example of the structure: \0engThis is the null terminated description\0This is the rest of the body of the frame There are a few other frames that use null terminated strings - APIC, POPM and the GEOB frames spring to mind. Tom is right thought, if you are only going to be using Winamp to play your music then you need only code around the v2.3.0 std as later versions of ID3 are not supported by Winamp. Hope this helps, Andy. ----- Original Message ----- From: "Tom Sorensen" To: Sent: Thursday, October 27, 2005 2:16 PM Subject: Re: [ID3 Dev] Info Sought Again, do not use ID3v2.4 if you want Winamp to read the results. Winamp will not read any v2.4 tags. You need to use http://www.id3.org/id3v2.3.0.html as your reference instead. As for VB libraries, I do not know VB, but if you Google for "vb id3" there seems to be a good number of hits, including this: http://www.pstruh.cz/tips/detpg_change-id3-tags-script/ I can answer at least one of your questions... > The next byte is (always?) a zero and the actual information starts > after that. No, that byte is part of the frame data (you must include it in frame length!), is only present for text field data, and indicates if the data is Unicode or not. The reference to it in the ID3v2.3 docs is rather buried though, so here it is: "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." Note that for ID3v2.3 "Unicode" means UTF-16. v2.4 is more flexible, but, again, I recommend against using it if you want to use Winamp. --------------------------------------------------------------------- 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 chris.newell at rd.bbc.co.uk Mon Oct 17 01:47:35 2005 From: chris.newell at rd.bbc.co.uk (Chris Newell) Date: Mon, 17 Oct 2005 09:47:35 +0100 Subject: [ID3 Dev] Chapter frame API In-Reply-To: <00f801c5d131$106b3030$3701a8c0@eapac.ericsson.se> References: <6.1.2.0.2.20051012113938.030a7af0@pop3> <00f801c5d131$106b3030$3701a8c0@eapac.ericsson.se> Message-ID: <6.1.2.0.2.20051017093240.02f790a8@pop3> At 03:35 15/10/2005, you wrote: >I have committed the latest vdHeide code (With bug fixes and ID3v2.2 to >ID3v2.3 conversion code) to a new sourceforge project. >This is now the official home of this library. I would ask anyone >interrested to contribute to send me an e-mail so I can add you to the >project. >Chris: Would love to have you on board to commit the CHAP & CTOC frames to >the latest code base. Christophe, I'd be happy to include the code but I think I should wait until ID3 has finalised the specification. Have you considered moving to an id3 namespace? i.e. org.id3.mp3 Chris >Please note, I am doing this on request from Jens himself, as we was happy >with bugfixes we committed to his code and had no time >himself to work on the library. The code is GPL. > >The project is barebone, no javadoc, build facilities. This will be added >gradually. > >Cheers / Christophe > > > > > >----- Original Message ----- >From: "Chris Newell" >To: >Sent: Wednesday, October 12, 2005 6:51 PM >Subject: [ID3 Dev] Chapter frame API > > >> Hi, >> >> For anyone who may want to experiment with the proposed ID3v2 chapter >frames I've documented the Java API used by my Chapter authoring tool. This >API is built on top of the ID3 API developed by Jens Vonderheide and >provides classes to create or decode CHAP & CTOC frames. There are also some >utility classes for Text, URL and APIC frames. >> >> The javadoc is available at: >> >> http://id3v2-chap-tool.sourceforge.net/javadoc/index.html >> >> And the source is available at: >> >> >http://cvs.sourceforge.net/viewcvs.py/id3v2-chap-tool/ID3v2ChapterTool/src >> >> Chris >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr J.C. Newell Digital Media Group, BBC Research & Development Kingswood Warren, Woodland Way, Tadworth, Surrey KT20 6NP UK mailto:chris.newell at rd.bbc.co.uk http://www.bbc.co.uk/rd Tel: +44 (0)1737 839659 Switchboard: +44 1737 839500 Fax: +44 (0)1737 839665 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------------------------------------------------------------- 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 Oct 26 06:11:09 2005 From: tsorensen at gmail.com (Tom Sorensen) Date: Wed, 26 Oct 2005 09:11:09 -0400 Subject: [ID3 Dev] Info Sought In-Reply-To: <435EF348.9060809@xtra.co.nz> References: <435EF348.9060809@xtra.co.nz> Message-ID: <4da424620510260611k7eef734o6df98094133c5359@mail.gmail.com> I highly recommend finding an ID3 library for VB and using that. Writing your own is certainly doable, but there are a lot of nuances in the tag format, and if you get them wrong then other programs may have problems reading your files. As far as Winamp goes -- it produces clean tags, but realize that they are ID3v2.3 tags, not 2.4. Make sure you're looking at the right version of the standard. It also uses an expanded list of ID3v1 genres, so that's something to be aware of as well. On 10/25/05, Kirk McMillan wrote: > Dear List, > > I'm a newbie with ID3V2 tags. My aim to is write a VB routine within > MSAccess to tag > my albums automatically (as they're riped to mp3 format). > > I have read the structure doc by Martin Nilsson. > > Some of the statements seem to be at odds with my findings as I > interpret frame information (in Winamp). > Some I simply don't understand and I'm sure there's more to consider. > > Is this the place for specfic questions. Or, should I be looking > elsewhere ? FAQ etc ? > > With thanks, > Kirk > > > --------------------------------------------------------------------- > 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 bmearns at coe.neu.edu Fri Oct 28 15:18:01 2005 From: bmearns at coe.neu.edu (Brian Mearns) Date: Fri, 28 Oct 2005 18:18:01 -0400 Subject: [ID3 Dev] Padding Size in v2.3 extended header Message-ID: <4362A399.2050300@coe.neu.edu> In ID3v2.3.0, is the Padding Size field in the ID3 Tag Extended Header sync-safe? Thanks. -Brian --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From andrew.kernahan at btinternet.com Sat Oct 29 00:47:06 2005 From: andrew.kernahan at btinternet.com (Andy Kernahan) Date: Sat, 29 Oct 2005 08:47:06 +0100 Subject: [ID3 Dev] Padding Size in v2.3 extended header References: <4362A399.2050300@coe.neu.edu> Message-ID: <000801c5dc5c$f6101c00$0500000a@MARVIN> Brian, the extended header is subject to unsynchronisation (if applied), so the padding field is not sync-safe. Andy. ----- Original Message ----- From: "Brian Mearns" To: "Id3v2 Mailing List" Sent: Friday, October 28, 2005 11:18 PM Subject: [ID3 Dev] Padding Size in v2.3 extended header > In ID3v2.3.0, is the Padding Size field in the ID3 Tag Extended Header > sync-safe? > > Thanks. > > -Brian > > > --------------------------------------------------------------------- > 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 kirkm at xtra.co.nz Tue Oct 25 20:08:56 2005 From: kirkm at xtra.co.nz (Kirk McMillan) Date: Wed, 26 Oct 2005 16:08:56 +1300 Subject: [ID3 Dev] Info Sought Message-ID: <435EF348.9060809@xtra.co.nz> Dear List, I'm a newbie with ID3V2 tags. My aim to is write a VB routine within MSAccess to tag my albums automatically (as they're riped to mp3 format). I have read the structure doc by Martin Nilsson. Some of the statements seem to be at odds with my findings as I interpret frame information (in Winamp). Some I simply don't understand and I'm sure there's more to consider. Is this the place for specfic questions. Or, should I be looking elsewhere ? FAQ etc ? With thanks, Kirk --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From id3v2 at northpb.com Wed Oct 19 21:16:10 2005 From: id3v2 at northpb.com (Dan O'Neill) Date: Wed, 19 Oct 2005 21:16:10 -0700 Subject: [ID3 Dev] Update on ID3 Chapter tag publication efforts In-Reply-To: <20051020013244.GA3665@ayup.limey.net> References: <4356D5B6.4060709@northpb.com> <20051020013244.GA3665@ayup.limey.net> Message-ID: <43571A0A.4040302@northpb.com> Ben Bennett wrote: > If we are updating the ID3.org website can we put a clarification out > saying that ID3v2.4 frame sizes are SYNCSAFE. Certain popular > programs (iTunes, and others) do not do that. > > Of course since they have so messed up people's tags and there will be > no way to untangle them perhaps a new version (2.5 or 2.4.1) would > make sense? > > -ben Hi Ben, Love to put up something. I don't know as much about the issues as you do. Could you draft up something? or point me to someplace that has described the issue and I'll write up something for you to review. As for iTunes and the other applications, if you can help to clearly state what they do wrong, I'll get it in the hands of the Napster folks and quite possibly the others as well. Dan --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From chris.newell at rd.bbc.co.uk Fri Oct 28 03:32:00 2005 From: chris.newell at rd.bbc.co.uk (Chris Newell) Date: Fri, 28 Oct 2005 11:32:00 +0100 Subject: [ID3 Dev] Rev 3 of CTOC/CHAP frame standard published In-Reply-To: <435F9EE1.2020605@northpb.com> References: <435F9EE1.2020605@northpb.com> Message-ID: <6.1.2.0.2.20051027094348.02d506c8@pop3> At 16:21 26/10/2005, Dan O'Neill wrote: >The developers page has been udpated to reflect revision 3 of the CTOC/CHAP frame standard. > >http://www.id3.org/develop.html > >Has anyone created an alpha version of a tag editor / player that supports CTOC and CHAP frames? Dan, Although I've mentioned the Chapter frame APIs and authoring tool before, it's probably worth mentioning that I've updated them to conform with revision 3 of the draft CTOC/CHAP frame standard. I've also switched to the latest version of the Jens Vonderheide API, which was recently published on Sourceforge by Christophe Bouhier. The chapter tool (http://sourceforge.net/projects/id3v2-chap-tool) can add CTOC & CHAP frames to tagged or untagged audio files. However, it would be really good to see a working player out there. Chris ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dr J.C. Newell Digital Media Group, BBC Research & Development Kingswood Warren, Woodland Way, Tadworth, Surrey KT20 6NP UK mailto:chris.newell at rd.bbc.co.uk http://www.bbc.co.uk/rd Tel: +44 (0)1737 839659 Switchboard: +44 1737 839500 Fax: +44 (0)1737 839665 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From andrew.kernahan at btinternet.com Thu Oct 27 14:12:43 2005 From: andrew.kernahan at btinternet.com (Andy Kernahan) Date: Thu, 27 Oct 2005 22:12:43 +0100 Subject: [ID3 Dev] Info Sought References: <435EF348.9060809@xtra.co.nz> <000a01c5da2e$5cb69eb0$0500000a@MARVIN> <43603072.8040002@xtra.co.nz> <4da424620510270616n21206296v6f760b7f7404132c@mail.gmail.com> <000a01c5db23$6f494be0$0500000a@MARVIN> Message-ID: <000b01c5db3b$2c530980$0500000a@MARVIN> Opps, sorry. The maximum safe-sync value is 0xFFFFFFF. Andy. ----- Original Message ----- From: "Andy Kernahan" To: Sent: Thursday, October 27, 2005 7:22 PM Subject: Re: [ID3 Dev] Info Sought > Kirk, > > the answer to your other question is 7F 7F 7F 7F for a maximum value > sync-safe integer. As the for the comment frame it has the following > structure: > > text encoding ID (1byte), > language ID (3bytes (3 ASCII chars)), > description (null terminated (\0)), > body of text. > > Below is an example of the structure: > > \0engThis is the null terminated description\0This is the rest of the body > of the frame > > There are a few other frames that use null terminated strings - APIC, POPM > and the GEOB frames spring to mind. > Tom is right thought, if you are only going to be using Winamp to play > your music then you need only code around the v2.3.0 std as later versions > of ID3 are not supported by Winamp. > > Hope this helps, > > Andy. > > ----- Original Message ----- > From: "Tom Sorensen" > To: > Sent: Thursday, October 27, 2005 2:16 PM > Subject: Re: [ID3 Dev] Info Sought > > > Again, do not use ID3v2.4 if you want Winamp to read the results. > Winamp will not read any v2.4 tags. You need to use > http://www.id3.org/id3v2.3.0.html as your reference instead. > > As for VB libraries, I do not know VB, but if you Google for "vb id3" > there seems to be a good number of hits, including this: > http://www.pstruh.cz/tips/detpg_change-id3-tags-script/ > > I can answer at least one of your questions... > >> The next byte is (always?) a zero and the actual information starts >> after that. > > No, that byte is part of the frame data (you must include it in frame > length!), is only present for text field data, and indicates if the > data is Unicode or not. The reference to it in the ID3v2.3 docs is > rather buried though, so here it is: > > "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." > > Note that for ID3v2.3 "Unicode" means UTF-16. v2.4 is more flexible, > but, again, I recommend against using it if you want to use Winamp. > > --------------------------------------------------------------------- > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From kirkm at xtra.co.nz Wed Oct 26 18:42:10 2005 From: kirkm at xtra.co.nz (Kirk McMillan) Date: Thu, 27 Oct 2005 14:42:10 +1300 Subject: [ID3 Dev] Info Sought In-Reply-To: <000a01c5da2e$5cb69eb0$0500000a@MARVIN> References: <435EF348.9060809@xtra.co.nz> <000a01c5da2e$5cb69eb0$0500000a@MARVIN> Message-ID: <43603072.8040002@xtra.co.nz> Hi Andy, OK I will. Thanks ! I need to ascertain one fact. The document I have (id3.org/id3v2.4.0-structure.txt) says each frame header consists of 10 bytes. The next byte is (always?) a zero and the actual information starts after that. Is the frame header actually 11 bytes, or does the information require a leading zero, ignored by the reader ? Some fields (COMM only I believe) have extra bytes consisting of "0 eng 0". When this is present, can it be detected in the frame header, or should the reader check for it ? If the highest number that can be represented in the 32 bit synchsafe integer can store 28 bits of information, are these bytes values 7F 7F 7F 7F. Or are they 15 FF FF FF ? Hope that's not too much at once. Thanks - Kirk Andy Kernahan wrote: > Kirk, > > fire away with whatever questions you have, this is a place for > both specifics and for more general questions. > > Andy. > > > ----- Original Message ----- From: "Kirk McMillan" > To: > Sent: Wednesday, October 26, 2005 4:08 AM > Subject: [ID3 Dev] Info Sought > > >> Dear List, >> >> I'm a newbie with ID3V2 tags. My aim to is write a VB routine within >> MSAccess to tag >> my albums automatically (as they're riped to mp3 format). >> >> I have read the structure doc by Martin Nilsson. >> >> Some of the statements seem to be at odds with my findings as I >> interpret frame information (in Winamp). >> Some I simply don't understand and I'm sure there's more to consider. >> >> Is this the place for specfic questions. Or, should I be looking >> elsewhere ? FAQ etc ? >> >> With thanks, >> Kirk >> >> >> --------------------------------------------------------------------- >> 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From deathboy2000 at earthlink.net Sun Oct 30 21:57:04 2005 From: deathboy2000 at earthlink.net (darien) Date: Sun, 30 Oct 2005 22:57:04 -0700 Subject: [ID3 Dev] questions regarding TBPM frame. Message-ID: <6.2.5.6.0.20051030223858.02ecdb90@earthlink.net> hi there. i have a quick question for this list ... i combed through the documents on id3.org, and even attempted to contact martin nilsson via email with my questions but never received a reply, and i am in need of some sort of answer, so i thought i would join the list and ask. i apologize if the information i'm asking for seems trivial or if it is indeed answered on the id3.org site and i just missed it. my question primarily pertains to the id3v2.x TBPM frame. as far as the TBPM frame is concerned, what is allowed, convention-wise, and what is deemed improper for data contained in this frame? ie, would the following types of BPM data be 'legal' within the convention of this frame: 12781 127.81 are there any limitations on this frame with regard to size, length, or type of data entered into this frame? the reason why i am asking is this. i am a user and beta tester for a piece of software called Traktor, which is basically a piece of software that allows you to DJ using mp3 files (as well as a myriad of other audio file types). the software, when importing mp3 files into the program, does analyzation of the file to create a 'stripe', which contains a representation of what the mp3's waveform looks like and so forth, and reads the id3 tag for information about the song and puts that in its' database. at this point in time, when it reads the bpm data stored in the TBPM frame, if data longer than 3 digits exists or if a decimal place exists in the frame, the software rounds the BPM data contained in the frame off to three digits and then re-writes it to the tag itself. ie: if the data in the frame equals 13279, the software rounds the digits off to 133 and re-writes the rounded-off TBPM frame back into the tag. i contend that this behaviour is wrong, as i do not like it rounding off my bpm data contained in the TBPM frame to 3-digit numbers -- i bothered to change them to reflect 10th and 100ths, and i'd like them to stay that way. i have tried to get the programmers of Traktor to fix the problem so that my frame data in the id3 tags i've spent hours working on aren't overwritten or messed with in anyway ... but the programmers seem to think that the id3v2.x standard doesn't support the frame data the way i've been entering it. the official word from them is : "That's actually a problem with the id3 standard - it only supports integer BPM. so all editors, including traktor, that show higher precision use a custom tag and are thus not compatible with each other." and "a 5 digit bpm in the TBPM-frame is as far as i know non-standard. basically everyone can scale as he wishes which makes the so-called standard to a not-really-standard-at-all :(" every tag editor that i've ever used (DrTag+ and Tag and Rename being two of the ones i've tried) have all allowed me to enter 5 digits (with or without a decimal place, ie 132.78 or 13278) into the frame without a problem and there doesn't seem to be a limit that i can see. so, my question is : what is the standard for the TBPM frame? are there any limitations? any information would be greatly appreciated! i would really like them to fix it so my tags don't get clobbered anymore! :) cheers and thanks in advance, --darien! --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From pschmitz at yahoo-inc.com Tue Oct 18 15:52:09 2005 From: pschmitz at yahoo-inc.com (Patrick Schmitz) Date: Tue, 18 Oct 2005 15:52:09 -0700 Subject: [ID3 Dev] ID3 chapter tags feedback In-Reply-To: <6.1.2.0.2.20051014170310.03049838@pop3> Message-ID: <200510182250.j9IMov6p049035@mrout2.yahoo.com> Hi Chris - Hi Chris - Thanks for your comments and responses. Knowing the TV-Anytime heritage helps a bit - I am also familiar with that (I went to some of those meetings as well). Am beginning to wonder if we have met somewhere along the way... I can see the point of using the absolute offsets for the leaf items, and I think I see the parallel to the TV-Anytime model (which in turn was based upon something like the DVD model, AIUI). For author time work, we would of course use something a little more flexible, but we could flatten this for export to ID3 tags. I was forgetting that this is based upon a model for only 1 output channel, and so there is no need for anything like sync, and there is no way to talk about a mix of two or more items - e.g. allowing voice over some music where this is actually mixed on the client. I presume that this sort of functionality will be left to SMIL (et al.)? So I think I am clearer on the TOC model of indicating whether there is a sensible sequence of the children, or not. I presume that for the case of "not", the presumption is that the items would be selected in some interactive manner. In that case, the SMIL analogs are SEQ and EXCL rather than SEQ and PAR. The "EXCL" time container constrains the playback to only allow one child at a time, but does not impose any ordering the way SEQ does. You can think of SEQ as a subclass of EXCL that adds sequential ordering. SMIL EXCL also adds interrupt semantics (so you can pause a "main" track to play other tracks, and the main track resumes when the interrupting track completes). This sounds like it is more than what you want for this application, but I thought I would mention it. I have one more question, however. Why do you constrain a CTOC element to only have one class of children? I have a number of use-cases I sketched out that would be more cumbersome with this constraint, and so I was wondering what the rationale was. Is there not a unified ID-space for the chapter and CTOC elements? I have attached a simple drawing of the problem I am thinking about. TOC1 is a CTOC with seq semantics, and describes the complete program as a sequence of basic segments. Segments 1 and 3 have a set of proper subsegments. Segments 6 and 7 are orthogonal segments. The spec as is requires that I define a CTOC proxy for segments 6 and 7 in order to place them into TOC0 along with TOC1. Similarly, since Seg1 and 3 must be CTOCs to describe the sequence semantics of their respective subsegments, Segments 2, 4 and 5 must all have CTOC proxy elements that exist only to point to the respective Chapter elements from within the TOC1 element. Thanks - Patrick > -----Original Message----- > From: Chris Newell [mailto:chris.newell at rd.bbc.co.uk] > Sent: Monday, October 17, 2005 2:25 AM > To: Patrick Schmitz > Cc: id3v2 at id3.org > Subject: Re: [ID3 Dev] ID3 chapter tags feedback > > Patrick, > At 00:53 14/10/2005, you wrote: > >Hi - I am new to this list, having just heard about the chapter tags > work. I am a researcher at Yahoo Berkeley, working on annotation of time > based media, and so we are naturally interested in the work going on with > Chapter tagging of MP3 content. > > > >My colleagues and I went through the docs today, and our first impression > is that we like much of what we see. We have a couple of clarifying > questions, and some suggestions. I am no expert on MP3 "syntax" and header > constraints, so forgive me if I make some silly suggestions that are not > in the spirit of MP3. > > > >My background is with XML formats, and especially SMIL [*]. As such, I > was translating in my head from the descriptions I read to how I think > about descriptions for timing. I hope this is useful both from the > perspective of clarifying the semantics as expressed in your docs, and as > an introduction to producing a description of an XML schema that would > parallel your work (e.g., as an interchange language for tools producing > ID3 Chapter frames). > > > >In SMIL timing [**], there are two common time containers: "par" (for > parallel) and "seq" (for sequence or sequential). Children of par elements > have timing relative to the par, but can overlap one another with few > constraints. Children of a seq are defined to be a sequence, and are > constrained to play one after another, possibly with delays between any > two items. While SMIL is defined for synchronization, the basic concepts > can be applied to this case as a description of the relationship of the > chapters in a CTOC element. It looks to me like CTOC plus the "Ordered > bit" in the flags is more or less equivalent to this - am I right? > > Yes. I'm not very familiar with SMIL but this sounds like an identical > concept. > > >In the spec, the Chapter start time and end time are defined as being > relative to the beginning of the file, and yet the CTOC structure implies > that there is a hierarchy of chapter elements. I would think that it makes > more sense to have the timing reflect the TOC structure. Thus if I have > defined a major section of the file as a chapter, I can describe pieces > within that section relative to the section begin, rather than from the > beginning of the file. This means that start times and byte offsets must > be added together to find an absolute offset into the file, but it also > means that excerpting a section of the whole file is more straightforward > (only the top-level offsets change). > > > >This would of course require that the CTOC elements also have timing > information - does that conflict very much with your current thinking? > > Although I can see the advantages during editing I think we should use > absolute offsets within ID3 tags as this makes life easier for media > players (often low profile devices). > > Relative offsets would also break a useful feature of the current proposal > - it's possible to refer to a CHAP frame from more than one CTOC. This > allows you to provide more than one table of contents for a single file. > e.g. for the recording of a rock festival you could provide: > - a full, temporally ordered table of contents > - a table providing an index of band names > - a table listing highlights > > >We've been playing with some syntax to describe temporal extents in media > as part of an annotation framework. We are developing the XML syntax for > this now, but I can say that it borrows from SMIL timing syntax (although > a good deal more constrained (simpler) than the expressivity of SMIL 2.0 > Timing. We are hoping that this would meld well with the ID3 chapter tags > work, allowing us a means of encapsulating our semantics in an MP3 file. > Have you done anything yet in the area of an XML syntax for the ID3 > chapter tags? We'd be happy to contribute to such an effort. > > The inspiration for the chapter frame proposal was an open standard for > Personal Video Recorders called "TV-Anytime" (http://www.tv-anytime.org/) > which I've worked on for a number of years. TV-Anytime has an XML schema > which supports chapters (they call it segmentation) and this maps quite > well with the binary structures used in the ID3 chapter frame proposal. > > Best regards, > > Chris > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Dr J.C. Newell > Digital Media Group, BBC Research & Development > Kingswood Warren, Woodland Way, Tadworth, Surrey > KT20 6NP UK > mailto:chris.newell at rd.bbc.co.uk http://www.bbc.co.uk/rd > Tel: +44 (0)1737 839659 > Switchboard: +44 1737 839500 > Fax: +44 (0)1737 839665 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: id3v2-unsubscribe at id3.org > For additional commands, e-mail: id3v2-help at id3.org > -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 2981 bytes Desc: not available URL: -------------- next part -------------- --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From andrew.kernahan at btinternet.com Mon Oct 31 15:56:53 2005 From: andrew.kernahan at btinternet.com (Andy Kernahan) Date: Mon, 31 Oct 2005 23:56:53 -0000 Subject: [ID3 Dev] questions regarding TBPM frame. References: <6.2.5.6.0.20051030223858.02ecdb90@earthlink.net> <6.2.5.6.0.20051031034035.02e9f310@earthlink.net> Message-ID: <000901c5de76$c4d6b600$0500000a@MARVIN> Darien, the ID3v2.X.0 standard clearly states that the TBPM frame contains a string representation of an integer, so the values 132.68 and 95.35 are invalid. I would not personally recommend changing the current specification of the TBPM frame to allow for high precision bpm values but instead I would suggest you submit a proposal for a new frame (PBPM?). This would allow TBPM aware applications to prefer the high precision frame over the standard TBPM frame whilst also ensuring that existing non-aware applications remain intact. Andy. ----- Original Message ----- From: "darien" To: Sent: Monday, October 31, 2005 2:07 PM Subject: Re: [ID3 Dev] questions regarding TBPM frame. > > hey there Pyt ... > > thanks for replying. > >>Strictly speaking, TBPM is a text frame, so it is very possible for it to >>be set to just about anything textual if a program would allow it. >>However, the v2.4 spec is pretty clear that it is an integer and that it >>is beats per minute, so you cannot set it to 123.45, and even though you >>could set it to 12345, but that would probably meaningless from a musical >>standpoint... >> >>I guess your programmer must have decided that more than 999 beats per >>minute is nonsense, which can be understood but is indeed going a bit >>further than the spec intends. >> >>Not sure this helps... > > it sort of does ... it's brought a couple of things to light, and i have a > question... > > how does one go about getting the spec for the TBPM frame changed to allow > for a decimal place and 'non-whole' bpm measurements (ie 132.68, 95.35, > etc) as allowable and legitimate data for the spec? > > i feel that it's not right the way it is, i can think of quite a few > arguments for why the 'standard' should be changed to allow a decimal > place if desired or needed, and i'd like to push to have it changed. it > would make my life a bit easier in a few different ways, and i reckon it > would probably help other people out there as well. > > bpm measurement is *never* a solid, honest-to-goodness integer. well, not > practically, anyway. it's usually measured in averages, because there are > no recordings out there that are perfectly on-beat from start to finish > ... there are many obvious reasons why... neither midi clocks nor human > drummers are ever 100% on the money with regard to keeping time, hence > having bpm measurements of 132.68, 95.35, etc. while midi clocks come > close, there's always a little bit of slide with regard to the accuracy of > its' generation. human drummers are never 100% -- every human drummer is > always off the mark by some percentage (usually depending on how drunk > they are). the only thing that is pretty much right-on is smpte, and a > large percentage of professional musicians don't use smpte for clock > generation (though there are a few out there that do, especially if > they're working in hollywood on film or television projects). > > most software applications that measure bpm properly do not end up with a > bpm measurement that is a whole integer either (here's one i know of > that's free and writes the value into the id3v2.x tag : > http://www.mixmeister.com/download_freestuff.html ) ... > > i'm a dance music dj and i play a lot of electronically-based music. i > play house, prog house, hip hop, breaks, and i play some mobile dj gigs > too if the money's right. years ago, i used to exclusively dj with vinyl > records and cd's, but now i use traktor dj studio to dj with. traktor dj > studio has the ability to be able to control/manipulate playback of mp3's > using a special hardware audio interface and vinyl records with a > recording of timecode cut onto them. the timecode records tell the > computer what pitch the record is playing back at, where the needle is on > the record and so forth. the records and hardware are essentially a > control interface, and a brilliant one at that. > > about 80% of the mp3's i generate to dj with are from recordings of vinyl > records, because that's the medium of choice for dj'ing electronic > music -- a lot of prime stuff gets released on vinyl that never sees a > digital release, even in this digital world of ours. vinyl, as a rule, is > an imperfect medium, which opens up a pretty huge can o' worms in itself > with regard to bpm and speed in general. here are some examples of things > that cause timing issues with vinyl records: > > o - vinyl records are never perfectly flat. every record pressed (even a > 180 gram audiophile grade record) has a certain degree of warp to it. they > can be really close to flat, but never perfectly flat > o - the stamper plates used to press records are made of nickel, and a > high amount of pressure is placed on them for every record pressed -- it > takes 120 tons of pressure to press a vinyl record. as a result, every > pressing degrades the stampers slightly. stampers are only good for 1000 > pressings. after that, the stampers will have degraded enough to create a > noticably imperfect product and a new set of stampers must be used. > o - consistency of the vinyl material differs slightly from batch to batch > > couple these factors with a midi clock that doesn't generate time > perfectly and you've got a recording that isn't going to be anywhere near > perfect, timing and bpm measurement-wise. > > this is just one example. another that i could explore is disco or funk > tracks from the 70's... parliament, the bee gee's, gloria gaynor, cheryl > lynn, donna summer, etc. all of that stuff was recorded onto analog tape, > and human drummers were employed. analog tape stretches and shrinks with > temperature and general use. tape machines of the day weren't digitally > regulated, and no analog motor is perfect. pair those imperfections with a > human drummer and loads of disco or funk swing, and you've got a recording > that isn't anywhere near a whole integer bpm-wise. > > so yeah ... some good arguments there. ;) > > any advice on how to go about getting the spec changed for the TBPM field > would be greatly appreciated. > > cheers. > > --darien! > > > > --------------------------------------------------------------------- > 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 id3v2 at northpb.com Mon Oct 24 18:33:43 2005 From: id3v2 at northpb.com (Dan O'Neill) Date: Mon, 24 Oct 2005 18:33:43 -0700 Subject: [ID3 Dev] ID3 Chapter tags mentioned at Gearhead Message-ID: <435D8B77.5000707@northpb.com> Obsessed with music, Outlook list By Mark Gibbs, Network World, 10/24/05 Mark Gibbs This week we take a break from our current VoIP obsession and instead focus on some of our other obsessions. Music, for example. We have a large collection of digitized music and we'd like to preserve the context of an album's context. It's irritating to listen to an album we've ripped where the tracks on the original flowed from one to the next and the player pauses between each track because they were ripped into separate files. Of course you could rip the album to a single file but then you would not be able to easily find the start of any particular track. In short, your choices are imperfect playback or unmanageable content. If you, like us, have theorized about a standard to fix this, theorize no longer. A group called ID3 is working on a proposal to add table of contents and chapter data to any file that uses the ID3 tag. ... http://www.networkworld.com/columnists/2005/102405gearhead.html --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From christophe at kualasoft.com Fri Oct 14 19:37:11 2005 From: christophe at kualasoft.com (Christophe Bouhier) Date: Sat, 15 Oct 2005 10:37:11 +0800 Subject: [ID3 Dev] vdHeide opensource. References: <6.1.2.0.2.20051012113938.030a7af0@pop3> <00f801c5d131$106b3030$3701a8c0@eapac.ericsson.se> Message-ID: <010701c5d131$59e2b6c0$3701a8c0@eapac.ericsson.se> And the project is located here....... https://sourceforge.net/projects/vdheide-id3 ----- Original Message ----- From: "Christophe Bouhier" To: Cc: "Andreas Schaefer" ; "Andreas Schaefer" Sent: Saturday, October 15, 2005 10:35 AM Subject: Re: [ID3 Dev] Chapter frame API > Hi, > > I have committed the latest vdHeide code (With bug fixes and ID3v2.2 to > ID3v2.3 conversion code) to a new sourceforge project. > This is now the official home of this library. I would ask anyone > interrested to contribute to send me an e-mail so I can add you to the > project. > Chris: Would love to have you on board to commit the CHAP & CTOC frames to > the latest code base. > > Please note, I am doing this on request from Jens himself, as we was happy > with bugfixes we committed to his code and had no time > himself to work on the library. The code is GPL. > > The project is barebone, no javadoc, build facilities. This will be added > gradually. > > Cheers / Christophe > > > > > > ----- Original Message ----- > From: "Chris Newell" > To: > Sent: Wednesday, October 12, 2005 6:51 PM > Subject: [ID3 Dev] Chapter frame API > > > > Hi, > > > > For anyone who may want to experiment with the proposed ID3v2 chapter > frames I've documented the Java API used by my Chapter authoring tool. This > API is built on top of the ID3 API developed by Jens Vonderheide and > provides classes to create or decode CHAP & CTOC frames. There are also some > utility classes for Text, URL and APIC frames. > > > > The javadoc is available at: > > > > http://id3v2-chap-tool.sourceforge.net/javadoc/index.html > > > > And the source is available at: > > > > > http://cvs.sourceforge.net/viewcvs.py/id3v2-chap-tool/ID3v2ChapterTool/src > > > > Chris > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Dr J.C. Newell > > Digital Media Group, BBC Research & Development > > Kingswood Warren, Woodland Way, Tadworth, Surrey > > KT20 6NP UK > > mailto:chris.newell at rd.bbc.co.uk http://www.bbc.co.uk/rd > > Tel: +44 (0)1737 839659 > > Switchboard: +44 1737 839500 > > Fax: +44 (0)1737 839665 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > > --------------------------------------------------------------------- > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From andrew.kernahan at btinternet.com Wed Oct 26 06:08:30 2005 From: andrew.kernahan at btinternet.com (Andy Kernahan) Date: Wed, 26 Oct 2005 14:08:30 +0100 Subject: [ID3 Dev] Info Sought References: <435EF348.9060809@xtra.co.nz> Message-ID: <000a01c5da2e$5cb69eb0$0500000a@MARVIN> Kirk, fire away with whatever questions you have, this is a place for both specifics and for more general questions. Andy. ----- Original Message ----- From: "Kirk McMillan" To: Sent: Wednesday, October 26, 2005 4:08 AM Subject: [ID3 Dev] Info Sought > Dear List, > > I'm a newbie with ID3V2 tags. My aim to is write a VB routine within > MSAccess to tag > my albums automatically (as they're riped to mp3 format). > > I have read the structure doc by Martin Nilsson. > > Some of the statements seem to be at odds with my findings as I interpret > frame information (in Winamp). > Some I simply don't understand and I'm sure there's more to consider. > > Is this the place for specfic questions. Or, should I be looking elsewhere > ? FAQ etc ? > > With thanks, > Kirk > > > --------------------------------------------------------------------- > 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 id3v2 at northpb.com Wed Oct 12 10:49:05 2005 From: id3v2 at northpb.com (Dan O'Neill) Date: Wed, 12 Oct 2005 10:49:05 -0700 Subject: [ID3 Dev] CTOC and CHAP standards draft 2005101201 available In-Reply-To: <6.1.2.0.2.20051012113938.030a7af0@pop3> References: <6.1.2.0.2.20051012113938.030a7af0@pop3> Message-ID: <434D4C91.3040202@northpb.com> Chris Newell has been working diligently on the Chapter Table of Contents and Chapter tag format standard. A new release of the proposed standard is now available for review at the following location: http://id3.org/drafts Included in this release are the following files: http://www.id3.org/drafts/id3v2_chapters_2005101201.txt The text version of the 2005101201 draft of the CTOC/CHAP standard http://www.id3.org/drafts/CTOC-frame-2005101201.jpg A diagram of Chapter Table of Contents binary elements and structure. http://www.id3.org/drafts/CHAP-frame-2005101201.jpg A diagram of the Chapter binary elements and structure. You can help Chris and I move forward on getting this past the draft stage by the following: 1. Take a look through the documents and drawings and reply to the list with your comments, corrections and clarifications. (I am especially interested in publishing very clear specifications on how to use these tags so that the number of implementation questions will be small) 2. If you work on products such as Winamp, YME, MusicMatch Jukebox, iTunes, iPod or any playback or encoding platform that creates or reads ID3 tags, we want to hear from you especially. Tell us what you like, don't like, want to support, don't want to support. 3. If you know of a person who does work on the above apps, please forwardthem a copy of this note. We would very much like them in the discussion - subscribe to the mailing list by sending a message to id3v2-subscribe at id3.org Chris posted a reference implementation in Java this morning that matches the above revision of the tag specification. I'm including the URL's here for completeness. The javadoc is available at: http://id3v2-chap-tool.sourceforge.net/javadoc/index.html And the source is available at: http://cvs.sourceforge.net/viewcvs.py/id3v2-chap-tool/ID3v2ChapterTool/src Hope to hear from some of you shortly. Sincerely, dano --------------------------------------------------------------------- To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional commands, e-mail: id3v2-help at id3.org From tsorensen at gmail.com Thu Oct 27 06:16:11 2005 From: tsorensen at gmail.com (Tom Sorensen) Date: Thu, 27 Oct 2005 09:16:11 -0400 Subject: [ID3 Dev] Info Sought In-Reply-To: <43603072.8040002@xtra.co.nz> References: <435EF348.9060809@xtra.co.nz> <000a01c5da2e$5cb69eb0$0500000a@MARVIN> <43603072.8040002@xtra.co.nz> Message-ID: <4da424620510270616n21206296v6f760b7f7404132c@mail.gmail.com> Again, do not use ID3v2.4 if you want Winamp to read the results. Winamp will not read any v2.4 tags. You need to use http://www.id3.org/id3v2.3.0.html as your reference instead. As for VB libraries, I do not know VB, but if you Google for "vb id3" there seems to be a good number of hits, including this: http://www.pstruh.cz/tips/detpg_change-id3-tags-script/ I can answer at least one of your questions... > The next byte is (always?) a zero and the actual information starts > after that. No, that byte is part of the frame data (you must include it in frame length!), is only present for text field data, and indicates if the data is Unicode or not. The reference to it in the ID3v2.3 docs is rather buried though, so here it is: "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." Note that for ID3v2.3 "Unicode" means UTF-16. v2.4 is more flexible, but, again, I recommend against using it if you want to use Winamp. --------------------------------------------------------------------- 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 Mon Oct 31 00:25:06 2005 From: py.thoulon at gmail.com (Pyt) Date: Mon, 31 Oct 2005 09:25:06 +0100 Subject: [ID3 Dev] questions regarding TBPM frame. In-Reply-To: <6.2.5.6.0.20051030223858.02ecdb90@earthlink.net> References: <6.2.5.6.0.20051030223858.02ecdb90@earthlink.net> Message-ID: From the ID3v2.4 spec: TBPM The 'BPM' frame contains the number of beats per minute in the main part of the audio. The BPM is an integer and represented as a numerical string. Strictly speaking, TBPM is a text frame, so it is very possible for it to be set to just about anything textual if a program would allow it. However, the v2.4 spec is pretty clear that it is an integer and that it is beats per minute, so you cannot set it to 123.45, and even though you could set it to 12345, but that would probably meaningless from a musical standpoint... I guess your programmer must have decided that more than 999 beats per minute is nonsense, which can be understood but is indeed going a bit further than the spec intends. Not sure this helps... Regards, Pyt. On 10/31/05, darien wrote: > > id3.org site and i just missed it. > > my question primarily pertains to the id3v2.x TBPM frame. > > as far as the TBPM frame is concerned, what is allowed, > convention-wise, and what is deemed improper for data contained in > this frame? ie, would the following types of BPM data be 'legal' > within the convention of this frame: > > 12781 > 127.81 > > are there any limitations on this frame with regard to size, length, > or type of data entered into this frame? > -------------- next part -------------- An HTML attachment was scrubbed... URL: