From bmearns at coe.neu.edu  Fri Jun 16 03:56:39 2006
From: bmearns at coe.neu.edu (Brian Mearns)
Date: Fri, 16 Jun 2006 06:56:39 -0400
Subject: [ID3 Dev] Is it possible to 'lock' ID3 tags?
In-Reply-To: <BAY103-F966E0B12488D7FE4E7896D68A0@phx.gbl>
References: <BAY103-F966E0B12488D7FE4E7896D68A0@phx.gbl>
Message-ID: <44928E67.6000608@coe.neu.edu>

I believe there are flags you can set in the individual frame headers to 
*mark* them "read only", but it's only on a per-frame basis, not for the 
whole tag (so you couldn't stop anyone from adding frames). Plus, 
setting this flag is really just making a plea that no one changes it; 
it won't actually stop them from doing it, it just tells them you don't 
want them to.

-Brian

Marvin Hamlet wrote:
> Hello everyone.
> 
> As the subject suggests, I'm wondering if it is possible to produce a 
> tag editor that somehow locks the ID3 tags, so that once written, the 
> information cannot be overwritten. I suspect not, but if any group of 
> people might know for certain, I feel sure it is amongst the members of 
> this community.
> 
> I know it's possible to 'wrap & hide' the mp3 file in some way, but that 
> is not the ideal solution I'm looking for. I'm hoping that it is 
> possible to lock the ID3 metadata itself - though I have my concerns 
> that some methods may render the file unreadable to other players and 
> editors.
> 
> I'd really appreciate some feedback on this. Thanks in advance.
> 
> _________________________________________________________________
> The new MSN Search Toolbar now includes Desktop search! 
> http://join.msn.com/toolbar/overview
> 
> 
> ---------------------------------------------------------------------
> 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 iontodirel at yahoo.co.uk  Wed Jun 28 04:15:12 2006
From: iontodirel at yahoo.co.uk (Ion Todirel)
Date: Wed, 28 Jun 2006 11:15:12 +0000 (GMT)
Subject: [ID3 Dev] ID3v2 Tag Reader/Writer
In-Reply-To: <20060606223245.DFET9180.gx4.fuse.net@avoca>
Message-ID: <20060628111512.93786.qmail@web86904.mail.ukl.yahoo.com>

why you didn't signed your assembly?


----- Original Message ----
From: Mitchell S. Honnert <mitch at honnert.com>
To: id3v2 at id3.org
Sent: Wednesday, 7 June, 2006 1:32:39 AM
Subject: RE: [ID3 Dev] ID3v2 Tag Reader/Writer


Check out my .NET library, UltraID3Lib, at www.UltraID3Lib.com.  It?s free and supports most of the ID3v2 frame types.  
 
Incidentally, any feedback on the design or implementation of my library from the people on this group would be greatly appreciated.
 
 - Mitchell S. Honnert
 



From: Ion Todirel [mailto:iontodirel at yahoo.co.uk] 
Sent: Tuesday, June 06, 2006 5:47 PM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] ID3v2 Tag Reader/Writer
 
hey,
 
i want a .NET component that supports "some" of the ID3v2 tag, and able to read/write tags. At least a COM component.
 
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20060628/9d08bd34/attachment.html>

From mitch at honnert.com  Wed Jun 28 07:13:36 2006
From: mitch at honnert.com (Mitchell S. Honnert)
Date: Wed, 28 Jun 2006 10:13:36 -0400
Subject: [ID3 Dev] ID3v2 Tag Reader/Writer
References: <20060628111512.93786.qmail@web86904.mail.ukl.yahoo.com>
Message-ID: <001801c69abd$0c74de80$e3000105@kendle.com>

Ion, thanks for your question, but instead of taking any more of the group's bandwidth, I'll reply directly to your e-mail address.  If anyone else has any questions or feedback on UltraID3Lib, please e-mail UltraID3Lib at honnert.com.

 - Mitchell S. Honnert

  ----- Original Message ----- 
  From: Ion Todirel 
  To: id3v2 at id3.org 
  Sent: Wednesday, June 28, 2006 7:15 AM
  Subject: Re: [ID3 Dev] ID3v2 Tag Reader/Writer


  why you didn't signed your assembly?


  ----- Original Message ----
  From: Mitchell S. Honnert <mitch at honnert.com>
  To: id3v2 at id3.org
  Sent: Wednesday, 7 June, 2006 1:32:39 AM
  Subject: RE: [ID3 Dev] ID3v2 Tag Reader/Writer


  Check out my .NET library, UltraID3Lib, at www.UltraID3Lib.com.  It?s free and supports most of the ID3v2 frame types.  



  Incidentally, any feedback on the design or implementation of my library from the people on this group would be greatly appreciated.



   - Mitchell S. Honnert




------------------------------------------------------------------------------

  From: Ion Todirel [mailto:iontodirel at yahoo.co.uk] 
  Sent: Tuesday, June 06, 2006 5:47 PM
  To: id3v2 at id3.org
  Subject: Re: [ID3 Dev] ID3v2 Tag Reader/Writer



  hey,



  i want a .NET component that supports "some" of the ID3v2 tag, and able to read/write tags. At least a COM component.



  Thanks.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20060628/414a9351/attachment.html>

From mitch at honnert.com  Tue Jun  6 15:32:39 2006
From: mitch at honnert.com (Mitchell S. Honnert)
Date: Tue, 6 Jun 2006 18:32:39 -0400
Subject: [ID3 Dev] ID3v2 Tag Reader/Writer
In-Reply-To: <20060606214653.28375.qmail@web86902.mail.ukl.yahoo.com>
Message-ID: <20060606223245.DFET9180.gx4.fuse.net@avoca>

Check out my .NET library, UltraID3Lib, at www.UltraID3Lib.com.  It's free
and supports most of the ID3v2 frame types.  

 

Incidentally, any feedback on the design or implementation of my library
from the people on this group would be greatly appreciated.

 

 - Mitchell S. Honnert

 

  _____  

From: Ion Todirel [mailto:iontodirel at yahoo.co.uk] 
Sent: Tuesday, June 06, 2006 5:47 PM
To: id3v2 at id3.org
Subject: Re: [ID3 Dev] ID3v2 Tag Reader/Writer

 

hey,

 

i want a .NET component that supports "some" of the ID3v2 tag, and able to
read/write tags. At least a COM component.

 

Thanks.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20060606/fd1ebc72/attachment.html>

From tsorensen at gmail.com  Wed Jun  7 05:54:36 2006
From: tsorensen at gmail.com (Tom Sorensen)
Date: Wed, 7 Jun 2006 08:54:36 -0400
Subject: [ID3 Dev] I want to make my Java API OpenSource
In-Reply-To: <52852.195.91.54.86.1149616225.squirrel@webmail-4.domains.sk>
References: <52852.195.91.54.86.1149616225.squirrel@webmail-4.domains.sk>
Message-ID: <4da424620606070554l297ac2c3g794540ef99a1f141@mail.gmail.com>

To clarify what Scott said a bit, here's what happens if you release
your library under X license (loosely):

BSD/MIT (very similar): They are not required to publish any source,
only to acknowledge your library and indicate that you wrote it, not
them.
LGPL: As above, but they do have to publish changes they make to your source.
GPL: As above, plus they have to publish all of their own source code,
even if they link to it dynamically.

Note that LGPL is of questionable legal standing; it's never been
tested and there's a lot of weird "edge" cases (although I'm unsure
that they apply to Java). Both the BSD/MIT licenses and the GPL are
court tested (in the US at least) and solid.

There are many, many other OSS licenses as well, but those four are
the big ones, and most other licenses are similar in nature to one of
them.

On 6/6/06, Michal Vician <id3v2 at audiott.com> wrote:
> Hi!
>
> Maybe some of you know me. I've been for few months very busy because of
> school leaving exams. Fortunately, I passed all of them without any
> problems and now I have time for things I relly like - programming :-)
>
> Maybe you know freeware AudioTT which I have wrote. Now I want to publish
> my Java API that can handle almost everything related to MP3 and ID3 tags
> (using this API you can gain information about MP3 format, manipulate with
> ID3 v1/v2.3/v2.4 tag, it supports also new CHAP and CTOC frames ....).
>
> Is there anybody have some experiences with GPL, LGPL... licences, or
> anybody who would like to contribute etc.
>
> Just let me know please. I appreciate any help.
>
> Kind regards
> Miso
>
> ---
> Michal Vician
> id3v2 at audiott.com
> http://www.audiott.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> For additional commands, e-mail: id3v2-help at id3.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From wheeler at kde.org  Wed Jun 21 09:16:48 2006
From: wheeler at kde.org (Scott Wheeler)
Date: Wed, 21 Jun 2006 18:16:48 +0200
Subject: [ID3 Dev] Accessibilty extension draft is posted
In-Reply-To: <6.2.0.14.2.20060621120008.026cbcf8@pop3>
References: <448CCCD4.4060001@northpb.com> <200606161623.03066.wheeler@kde.org> <6.2.0.14.2.20060621120008.026cbcf8@pop3>
Message-ID: <200606211816.48302.wheeler@kde.org>

On Wednesday 21 June 2006 17:06, Chris Newell wrote:
> I'd be happy for the proposal to state that it is only appropriate for file
> formats that are compatible with the ID3 unsynchronisation scheme. The
> problem space is too big otherwise.

You might as well just say "MPEG audio" then, since that's pretty much the 
only format that the unsynchronization scheme is designed for.

> OK. An alternative solution could be to include a "Description" field so
> that each AudioText frame is uniquely associated with an equivalent text
> frame by a combination of:
>
>    Frame ID
>    Language Code
>    Description
>
> For frames where only one instance is permitted there is generally no
> "Description" field and therefore this would be set to $00.

That doesn't work, for instance, with the W... frames.  (i.e. WOAR)  Search 
through the frames spec for "more than one" and you'll see that there are a 
variety of formats used for frames that allow multiple instances.

It also doesn't address the problem of updating (when the audio and text go 
out of synch) mentioned in my last mail.

-Scott

-- 
The world is full of magical things patiently waiting for our wits to grow 
sharper. 
--Bertrand Russell

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From wheeler at kde.org  Fri Jun 16 08:22:37 2006
From: wheeler at kde.org (Scott Wheeler)
Date: Fri, 16 Jun 2006 17:22:37 +0200
Subject: [ID3 Dev] Accessibilty extension draft is posted
In-Reply-To: <20060616150034.GA8471@ayup.limey.net>
References: <448CCCD4.4060001@northpb.com> <200606161623.03066.wheeler@kde.org> <20060616150034.GA8471@ayup.limey.net>
Message-ID: <200606161722.37422.wheeler@kde.org>

On Friday 16 June 2006 17:00, Ben Bennett wrote:
> Remeber, unsync only matters if the player can't understand the ID3v2
> format.  If it knows how to at least read the header it can get the
> tag length and skip it all.

Again, it's not quite that simple when working with an open-ended set of 
formats and an open-ended set of players.  A lot of decoding happens in 
layers.  The layer that understands the container format and handles demuxing 
probably won't know about tags; a tag parser would be done with data once the 
higher levels had figured out which data to throw at it.

I don't have a ready-made software/format combo that I'm sure this would not 
work on, but I can just say that it's not far fetched that it would break in 
some places.

(A little background in multimedia file formats:  MPEG is really, really easy.  
It barely deserves to be called a format since it's pretty much raw data -- a 
codec more than a file format.  But with things like AVI or Ogg files or more 
robust audio-only formats you often have more specific requirements on 
placement of data and what strings are "stream flags" and shouldn't occur 
randomly.)

> That is cute.  I was going to say that this breaks simple updates,
> e.g. case changes or the like.  But your example shows why you _want_
> to break on things like that.  It probably makes sense to do the
> lookups with "cleaned up" strings (lowercase, leading and trailing
> whitespace stripped, internal whitespace reduced to one space).

That might be appropriate, but mind you that normalizing strings is actually 
trickier than it sounds (since it requires knowledge of the character sets 
being used.)

> Though if there is a long string duplicating it entirely may be excessive.

Nah.  The string size relative to the audio content will be insignificantly 
small.

-Scott

-- 
The fact that an opinion has been widely held is no evidence whatever that it 
is not utterly absurd. 
--Bertrand Russell

---------------------------------------------------------------------
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  Fri Jun 16 08:00:34 2006
From: fiji at ayup.limey.net (Ben Bennett)
Date: Fri, 16 Jun 2006 11:00:34 -0400
Subject: [ID3 Dev] Accessibilty extension draft is posted
In-Reply-To: <200606161623.03066.wheeler@kde.org>
References: <448CCCD4.4060001@northpb.com> <200606141426.04845.wheeler@kde.org> <6.2.0.14.2.20060614133403.025164f0@pop3> <200606161623.03066.wheeler@kde.org>
Message-ID: <20060616150034.GA8471@ayup.limey.net>

On Fri, Jun 16, 2006 at 04:23:02PM +0200, Scott Wheeler wrote:
> On Wednesday 14 June 2006 16:02, Chris Newell wrote:
> > The draft proposal recommends that unsynchronisation is applied but perhaps
> > this should be a mandatory if AudioText frames are present.

Remeber, unsync only matters if the player can't understand the ID3v2
format.  If it knows how to at least read the header it can get the
tag length and skip it all.

> One option might be instead of creating individual frames for each 
> corresponding text frame to create a dictionary of string -> audio pairs.
> 
> That would, incidentally get around another problem that I just thought of:  
> updating.
> 
> With the current draft, if you sent me a file with the genre set to "Jazz" and 
> a corresponding audio text frame, if I set it to "Blues" the content would be 
> out of synch.  Using a dictionary approach instead would mean that a lookup 
> for "Blues" would fail and (appropriately) there would be no corresponding 
> audio text.

That is cute.  I was going to say that this breaks simple updates,
e.g. case changes or the like.  But your example shows why you _want_
to break on things like that.  It probably makes sense to do the
lookups with "cleaned up" strings (lowercase, leading and trailing
whitespace stripped, internal whitespace reduced to one space).

Though if there is a long string duplicating it entirely may be excessive.
 
> > My view (and I'd be happy to be proved wrong) is that producing good
> > Computer Generated Speech on low profile devices like MP3 players is quite
> > hard whereas the implementation of AudioText frames is really simple.
> 
> That occurred to me after I sent this, but the thing that most occurs to me is 
> kind of a critical mass argument.  For this sort of information to be useful 
> in common practice it would require a large scale adoption -- i.e. having 
> this on 1% of MP3s wouldn't make devices as a whole usable.  A possible 
> solution would be to also develop an application that can do text generation 
> and automatically write these fields.

I think the idea is good in general.  Rockbox already has audio
navigation cues, I am not sure of the specifics, I just saw it in this
article: http://lwn.net/Articles/182633/

BTW Rockbox is aparently used a lot by the blind community and runs on
a lot of hardware (including iPods).  So if you make an automatic
generator and Rockbox adds support I think this will take off.

			-ben

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From wheeler at kde.org  Thu Jun 22 02:42:54 2006
From: wheeler at kde.org (Scott Wheeler)
Date: Thu, 22 Jun 2006 11:42:54 +0200
Subject: [ID3 Dev] Accessibilty extension draft is posted
In-Reply-To: <6.2.0.14.2.20060622092259.02619588@pop3>
References: <448CCCD4.4060001@northpb.com> <200606211816.48302.wheeler@kde.org> <6.2.0.14.2.20060622092259.02619588@pop3>
Message-ID: <200606221142.56676.wheeler@kde.org>

On Thursday 22 June 2006 11:07, you wrote:
> The original proposal was really intended for frames that carry human
> readable text strings as I didn't think it would be very useful to read out
> things like URLs.

Say it's a newscast from the BBC, would it not be useful to say, "news dot 
b-b-c dot home dot u-k"?

I'm just trying to think of this in systematic terms, not so much common-sense 
ones.  For the spec there would need to be, "Here are the places you can use 
this and here are the places you can't."  Ambiguity tends to come back to 
bite you...

> I see your point, although you can break most things with an authoring tool
> if you try hard enough!

Well, but this is just normal usage.  A user downloads a file, they decide 
that some part of the description is wrong and proceed to change it in their 
player of choice.

> I'm warming to the idea of a lookup table mapping strings to audio clips,
> since this would support any frame type and solves the multiple instance
> problem neatly. How about using a hash code approach to map strings to
> audio clips?

What would the hash be for?

If you mean to avoid string duplication, I think just duplicating the text 
would be easier to implement and easier to spec.  In terms of sizes, the text 
"Rolling Stones" including null termination is 15 bytes.  A two second, 96 
kb/s, 22050 kHz, mono mp3 is going to take around 5000 bytes.  Saving 7 bytes 
by using an 8 byte hash instead probably wouldn't be worth it, plus it'd make 
the files harder to read with a hex editor.  :-)

Cheers,

-Scott

-- 
We should forget about small efficiencies, say about 97% of the time: 
premature optimization is the root of all evil.
-Donald Knuth


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From bcorey at beatnik.com  Wed Jun  7 19:17:18 2006
From: bcorey at beatnik.com (Brandon Corey)
Date: Wed, 7 Jun 2006 19:17:18 -0700
Subject: [ID3 Dev] I want to make my Java API OpenSource
In-Reply-To: <4da424620606070554l297ac2c3g794540ef99a1f141@mail.gmail.com>
References: <52852.195.91.54.86.1149616225.squirrel@webmail-4.domains.sk> <4da424620606070554l297ac2c3g794540ef99a1f141@mail.gmail.com>
Message-ID: <20060608021718.GA26749@audioslave.beatnik.com>

FYI, this page has some basic information on pretty much every license
I've ever come across.

http://www.gnu.org/philosophy/license-list.html

Brandon

On Wed, Jun 07, 2006 at 08:54:36AM -0400, Tom Sorensen wrote:
> To clarify what Scott said a bit, here's what happens if you release
> your library under X license (loosely):
> 
> BSD/MIT (very similar): They are not required to publish any source,
> only to acknowledge your library and indicate that you wrote it, not
> them.
> LGPL: As above, but they do have to publish changes they make to your 
> source.
> GPL: As above, plus they have to publish all of their own source code,
> even if they link to it dynamically.
> 
> Note that LGPL is of questionable legal standing; it's never been
> tested and there's a lot of weird "edge" cases (although I'm unsure
> that they apply to Java). Both the BSD/MIT licenses and the GPL are
> court tested (in the US at least) and solid.
> 
> There are many, many other OSS licenses as well, but those four are
> the big ones, and most other licenses are similar in nature to one of
> them.
> 
> On 6/6/06, Michal Vician <id3v2 at audiott.com> wrote:
> >Hi!
> >
> >Maybe some of you know me. I've been for few months very busy because of
> >school leaving exams. Fortunately, I passed all of them without any
> >problems and now I have time for things I relly like - programming :-)
> >
> >Maybe you know freeware AudioTT which I have wrote. Now I want to publish
> >my Java API that can handle almost everything related to MP3 and ID3 tags
> >(using this API you can gain information about MP3 format, manipulate with
> >ID3 v1/v2.3/v2.4 tag, it supports also new CHAP and CTOC frames ....).
> >
> >Is there anybody have some experiences with GPL, LGPL... licences, or
> >anybody who would like to contribute etc.
> >
> >Just let me know please. I appreciate any help.
> >
> >Kind regards
> >Miso
> >
> >---
> >Michal Vician
> >id3v2 at audiott.com
> >http://www.audiott.com/
> >
> >
> >---------------------------------------------------------------------
> >To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
> >For additional commands, e-mail: id3v2-help at id3.org
> >
> >
> 
> ---------------------------------------------------------------------
> 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  Wed Jun 14 04:49:08 2006
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Wed, 14 Jun 2006 12:49:08 +0100
Subject: [ID3 Dev] Accessibility extension draft is posted
In-Reply-To: <448CCCD4.4060001@northpb.com>
References: <448CCCD4.4060001@northpb.com>
Message-ID: <6.2.0.14.2.20060614124442.02603ff0@pop3>

At 03:09 12/06/2006, Dan O'Neill wrote:
>Chris Newell's proposal for an Accessibility frame has been posted.

I anyone is interested there is a paper on the accessibility proposal at:

   http://www.bbc.co.uk/rd/pubs/whp/whp135.shtml 

which provides a bit more context.

Cheers,

Chris

>Abstract
>
>This document describes an extension which makes ID3v2 metadata accessible to the visually impaired. It may also be useful for audio players which have limited display capabilities. A new frame type is proposed that carries an audio clip which can provide a verbal expression of the textual information carried by any other ID3v2 frame.
>
>http://www.id3.org/id3v2-accessibility-1.0.html
>
>Links to the document are kept on the developers page.
>
>http://www.id3.org/develop.html
>
>dano

____________________________________________ 

Chris Newell 
Lead Technologist 
Technology Group
BBC New Media & Technology
Kingswood Warren, Woodland Way, Tadworth
Surrey  KT20 6NP   UK

Tel:    +44 (0)1737 839659
Fax:    +44 (0)1737 839665
mailto:chris.newell at rd.bbc.co.uk
   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20060614/8c2185b5/attachment.html>

From diskuze at cincura.net  Sat Jun 17 01:45:05 2006
From: diskuze at cincura.net (Jiri Cincura)
Date: Sat, 17 Jun 2006 10:45:05 +0200
Subject: [ID3 Dev] TCON frame in v2.3 vs. v2.4
Message-ID: <4493C111.8010601@cincura.net>

Hi *,

the TCON frame in ID3v2.3 is like (xy)Name, where the (xy) is optional. But 
in ID3v2.4 is xy#0Name and xy is stil optional, right?


-- 
Jiri Cincura
http://blog.vyvojar.cz/jirka/ | http://photo.cincura.net
http://www.ID3renamer.com

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From id3v2 at northpb.com  Sun Jun 11 19:09:24 2006
From: id3v2 at northpb.com (Dan O'Neill)
Date: Sun, 11 Jun 2006 19:09:24 -0700
Subject: [ID3 Dev] Accessibilty extension draft is posted
Message-ID: <448CCCD4.4060001@northpb.com>

Chris Newell's proposal for an Accessibility frame has been posted.

Abstract

This document describes an extension which makes ID3v2 metadata 
accessible to the visually impaired. It may also be useful for audio 
players which have limited display capabilities. A new frame type is 
proposed that carries an audio clip which can provide a verbal 
expression of the textual information carried by any other ID3v2 frame.

http://www.id3.org/id3v2-accessibility-1.0.html

Links to the document are kept on the developers page.

http://www.id3.org/develop.html

dano


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From marvmove at hotmail.com  Fri Jun 16 04:05:34 2006
From: marvmove at hotmail.com (Marvin Hamlet)
Date: Fri, 16 Jun 2006 11:05:34 +0000
Subject: [ID3 Dev] Is it possible to 'lock' ID3 tags?
In-Reply-To: <44928E67.6000608@coe.neu.edu>
Message-ID: <BAY103-F2609109A81A1880C17334ED6830@phx.gbl>

Thanks Brian and to you too, Paul Grebenc

I've had quite a lot of interest in this, which is why I've been trying to 
see if it could be done.
The best I could come up with for now was to make the audio files themselves 
'read only', which could hardly be considered secure.

I've actually got mixed feelings about it because I like the fact that I can 
choose what to include in my audio files and I'm sure that many other people 
do too.
The main reason behind the drive is to protect the files from incorrect 
data, misspellings, URLs and defacement.

Personally, I wouldn't have a clue how to actually implement your theory, 
but then, I'm the project manager. We plan to recruit a programmer to help 
us with the actual development of the editors/players we are designing, so 
if anyone in this community fancies a go, just let me know.

Thanks for the information though. It will help me in my quest, I am sure. 
:D


>From: Brian Mearns <bmearns at coe.neu.edu>
>Reply-To: id3v2 at id3.org
>To: id3v2 at id3.org
>Subject: Re: [ID3 Dev] Is it possible to 'lock' ID3 tags?
>Date: Fri, 16 Jun 2006 06:56:39 -0400
>
>I believe there are flags you can set in the individual frame headers to 
>*mark* them "read only", but it's only on a per-frame basis, not for the 
>whole tag (so you couldn't stop anyone from adding frames). Plus, setting 
>this flag is really just making a plea that no one changes it; it won't 
>actually stop them from doing it, it just tells them you don't want them 
>to.
>
>-Brian
>
>Marvin Hamlet wrote:
>>Hello everyone.
>>
>>As the subject suggests, I'm wondering if it is possible to produce a tag 
>>editor that somehow locks the ID3 tags, so that once written, the 
>>information cannot be overwritten. I suspect not, but if any group of 
>>people might know for certain, I feel sure it is amongst the members of 
>>this community.
>>
>>I know it's possible to 'wrap & hide' the mp3 file in some way, but that 
>>is not the ideal solution I'm looking for. I'm hoping that it is possible 
>>to lock the ID3 metadata itself - though I have my concerns that some 
>>methods may render the file unreadable to other players and editors.
>>
>>I'd really appreciate some feedback on this. Thanks in advance.
>>
>>_________________________________________________________________
>>The new MSN Search Toolbar now includes Desktop search! 
>>http://join.msn.com/toolbar/overview
>>
>>
>>---------------------------------------------------------------------
>>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
>

_________________________________________________________________
Are you using the latest version of MSN Messenger? Download MSN Messenger 
7.5 today! http://join.msn.com/messenger/overview


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From id3v2 at audiott.com  Tue Jun  6 11:39:51 2006
From: id3v2 at audiott.com (Michal Vician)
Date: Tue, 6 Jun 2006 20:39:51 +0200 (CEST)
Subject: [ID3 Dev] I want to make my Java API OpenSource
In-Reply-To: <23522.195.91.54.86.1149619094.squirrel@webmail-4.domains.sk>
References: <52852.195.91.54.86.1149616225.squirrel@webmail-4.domains.sk>   
    <!~!UENERkVCMDkAAQACAAAAAAAAAAAAAAAAABgAAAAAAAAArpBGj5e6kUWv+VUJ9aKPBMKAAAAQAAAAQ421Sf0Du0GicUbQLbr4lAEAAAAA@ripfactory.com>
    <23522.195.91.54.86.1149619094.squirrel@webmail-4.domains.sk>
Message-ID: <28428.195.91.54.86.1149619191.squirrel@webmail-4.domains.sk>


> I would like to make it OPEN SOURCE (nothing commercial), so anybody can
> use it and also freely contribute to make the API better... However, I
> don't really understand the diferences between GPL and LGPL. I'm stuck!
> Any ideas what would be the best thing to do in this situation?
>
> Miso
>
>
>>
>> Michal
>>
>> Do you want to publish this commercially , or just under GPL?
>>
>> Maybe I can help with the first option.
>>
>> Patrick
>>
>>
>>
>> -----Original Message-----
>> From: Michal Vician [mailto:id3v2 at audiott.com]
>> Sent: 06 June 2006 18:50
>> To: id3v2 at id3.org
>> Subject: [ID3 Dev] I want to make my Java API OpenSource
>>
>> Hi!
>>
>> Maybe some of you know me. I've been for few months very busy because of
>> school leaving exams. Fortunately, I passed all of them without any
>> problems
>> and now I have time for things I relly like - programming :-)
>>
>> Maybe you know freeware AudioTT which I have wrote. Now I want to
>> publish
>> my
>> Java API that can handle almost everything related to MP3 and ID3 tags
>> (using this API you can gain information about MP3 format, manipulate
>> with
>> ID3 v1/v2.3/v2.4 tag, it supports also new CHAP and CTOC frames ....).
>>
>> Is there anybody have some experiences with GPL, LGPL... licences, or
>> anybody who would like to contribute etc.
>>
>> Just let me know please. I appreciate any help.
>>
>> Kind regards
>> Miso
>>
>> ---
>> Michal Vician
>> id3v2 at audiott.com
>> http://www.audiott.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org For additional
>> commands,
>> e-mail: id3v2-help at id3.org
>


-- 
Michal Vician
id3v2 at audiott.com
http://www.audiott.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From wheeler at kde.org  Fri Jun 16 07:23:02 2006
From: wheeler at kde.org (Scott Wheeler)
Date: Fri, 16 Jun 2006 16:23:02 +0200
Subject: [ID3 Dev] Accessibilty extension draft is posted
In-Reply-To: <6.2.0.14.2.20060614133403.025164f0@pop3>
References: <448CCCD4.4060001@northpb.com> <200606141426.04845.wheeler@kde.org> <6.2.0.14.2.20060614133403.025164f0@pop3>
Message-ID: <200606161623.03066.wheeler@kde.org>

On Wednesday 14 June 2006 16:02, Chris Newell wrote:
> >Two things that jump out to me as bits that won't work:
> >
> >- You can't embed arbitrary audio into an ID3 tag and expect for it to be
> >decoded properly since it messes up synching.  For instance, with MPEG
> > audio, when you hit an MPEG synch frame, the audio player will just play
> > the stuff there like it's the first bit of audio content.  The rest of
> > the tag will be ignored.
>
> I discovered this to my cost when trying out a prototype:-) However, using
> the ID3v2 unsynchronisation scheme appeared to solve this.
>
> The draft proposal recommends that unsynchronisation is applied but perhaps
> this should be a mandatory if AudioText frames are present.

Unfortunately MPEG is the simple case.  Granted, the primary target of ID3 
files is MPEG audio, but they are used for some other things (FLAC comes to 
mind).  The absence of explicit unsynchronization for non-MPEG formats 
usually doesn't cause problems just because statistically it's not likely to 
accidentally have a properly formatted header.  However, if you're 
intentionally putting them in there, it could be problematic.

I'm not sure what a real solution is -- I'd be tempted to just use 
low-sampling frequency PCM, but that has its downsides too...

Also, speaking of synchs, the image in the draft shows a synch safe integer 
for the size, which would be really strange in an ID3v2.3 tag since they're 
not used there.

> >- Equivalent Frame ID doesn't work for frames that allow multiple
> > instances of the same frame.
>
> Couldn't you use multiple instances of AudioText frame with the same
> Equivalent Frame ID?
>
> It's true that in the current proposal you cannot assume a one-to-one
> relationship between a specific text frame and a specific AudioText frame
> if there are multiple instances with the same Equivalent Frame ID and
> language code.
>
> Would a satisfactory solution be to imply this relationship (if required)
> from the order in which they are found within the frame?

There's no guarantee that external taggers don't reorder frames when they 
write tags, so a third party tool just updating the tag would break things.

> >You also might want to consider if you want to do anything
> >special for frames that contain multiple, distinct strings.
>
> I had a hard think about this before coming up with the simple solution
> provided for frames like the COMM frame. My conclusion was that multiple
> audio clips were not necessarily helpful to the client user interface so
> the additional complexity might not be worthwhile.

One option might be instead of creating individual frames for each 
corresponding text frame to create a dictionary of string -> audio pairs.

That would, incidentally get around another problem that I just thought of:  
updating.

With the current draft, if you sent me a file with the genre set to "Jazz" and 
a corresponding audio text frame, if I set it to "Blues" the content would be 
out of synch.  Using a dictionary approach instead would mean that a lookup 
for "Blues" would fail and (appropriately) there would be no corresponding 
audio text.

> >(I must say that I'm somewhat sceptical of the uses of the extension in
> >general, vs., say, screen readers, but I'll take the time to read the
> > paper you just sent later on.)
>
> The paper does give a rationale for the proposed approach compared to the
> use of Computer Generated Speech.
>
> My view (and I'd be happy to be proved wrong) is that producing good
> Computer Generated Speech on low profile devices like MP3 players is quite
> hard whereas the implementation of AudioText frames is really simple.

That occurred to me after I sent this, but the thing that most occurs to me is 
kind of a critical mass argument.  For this sort of information to be useful 
in common practice it would require a large scale adoption -- i.e. having 
this on 1% of MP3s wouldn't make devices as a whole usable.  A possible 
solution would be to also develop an application that can do text generation 
and automatically write these fields.

With all this I don't mean to be overly negative -- just kind of playing 
devil's advocate from an engineering perspective...

-Scott

-- 
The three chief virtues of a programmer are: laziness, impatience and hubris.
--Larry Wall

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From wheeler at kde.org  Tue Jun  6 11:53:35 2006
From: wheeler at kde.org (Scott Wheeler)
Date: Tue, 6 Jun 2006 20:53:35 +0200
Subject: [ID3 Dev] I want to make my Java API OpenSource
In-Reply-To: <28428.195.91.54.86.1149619191.squirrel@webmail-4.domains.sk>
References: <52852.195.91.54.86.1149616225.squirrel@webmail-4.domains.sk> <23522.195.91.54.86.1149619094.squirrel@webmail-4.domains.sk> <28428.195.91.54.86.1149619191.squirrel@webmail-4.domains.sk>
Message-ID: <200606062053.50091.wheeler@kde.org>

On Tuesday 06 June 2006 20:39, Michal Vician wrote:
> I would like to make it OPEN SOURCE (nothing commercial), so anybody can
> use it and also freely contribute to make the API better... However, I
> don't really understand the diferences between GPL and LGPL. I'm stuck!
> Any ideas what would be the best thing to do in this situation?

The basic difference is that the GPL requires all things that are using your 
library to be Open Source also, whereas the LGPL allows non-Open Source 
applications to also use your library, but they still are required to publish 
any changes that they make to your library.

-Scott

-- 
The fact that an opinion has been widely held is no evidence whatever that it 
is not utterly absurd. 
--Bertrand Russell

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From jid3 at blinkenlights.org  Wed Jun  7 12:07:04 2006
From: jid3 at blinkenlights.org (Paul Grebenc)
Date: Wed, 7 Jun 2006 15:07:04 -0400 (EDT)
Subject: [ID3 Dev] Is it possible to 'lock' ID3 tags?
In-Reply-To: <BAY103-F966E0B12488D7FE4E7896D68A0@phx.gbl>
References: <BAY103-F966E0B12488D7FE4E7896D68A0@phx.gbl>
Message-ID: <Pine.LNX.4.63.0606071502250.24588@localhost.localdomain>

On Wed, 7 Jun 2006, Marvin Hamlet wrote:

> not the ideal solution I'm looking for. I'm hoping that it is possible to 
> lock the ID3 metadata itself - though I have my concerns that some methods

You can't prevent modification or removal of the tag.  If the tag you have 
is readable, then there's nothing stopping someone from changing it, or 
creating another tag to replace the one you've put on the file.

Your only chance to prevent tag modification is to disallow modification 
of the file itself.

Paul

---------------------------------------------------------------------
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 Jun 14 07:02:36 2006
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Wed, 14 Jun 2006 15:02:36 +0100
Subject: [ID3 Dev] Accessibilty extension draft is posted
In-Reply-To: <200606141426.04845.wheeler@kde.org>
References: <448CCCD4.4060001@northpb.com>
 <200606141426.04845.wheeler@kde.org>
Message-ID: <6.2.0.14.2.20060614133403.025164f0@pop3>

Hi Scott,

Many thanks for your comments.

>On Monday 12 June 2006 4:09, Dan O'Neill wrote:
>> Chris Newell's proposal for an Accessibility frame has been posted.

snip...

>Two things that jump out to me as bits that won't work:
>
>- You can't embed arbitrary audio into an ID3 tag and expect for it to be 
>decoded properly since it messes up synching.  For instance, with MPEG audio, 
>when you hit an MPEG synch frame, the audio player will just play the stuff 
>there like it's the first bit of audio content.  The rest of the tag will be 
>ignored.

I discovered this to my cost when trying out a prototype:-) However, using the ID3v2 unsynchronisation scheme appeared to solve this.

The draft proposal recommends that unsynchronisation is applied but perhaps this should be a mandatory if AudioText frames are present.

>- Equivalent Frame ID doesn't work for frames that allow multiple instances of 
>the same frame.

Couldn't you use multiple instances of AudioText frame with the same Equivalent Frame ID?

It's true that in the current proposal you cannot assume a one-to-one relationship between a specific text frame and a specific AudioText frame if there are multiple instances with the same Equivalent Frame ID and language code.

Would a satisfactory solution be to imply this relationship (if required) from the order in which they are found within the frame?

>You also might want to consider if you want to do anything 
>special for frames that contain multiple, distinct strings.

I had a hard think about this before coming up with the simple solution provided for frames like the COMM frame. My conclusion was that multiple audio clips were not necessarily helpful to the client user interface so the additional complexity might not be worthwhile.

>(I must say that I'm somewhat sceptical of the uses of the extension in 
>general, vs., say, screen readers, but I'll take the time to read the paper 
>you just sent later on.)

The paper does give a rationale for the proposed approach compared to the use of Computer Generated Speech.

My view (and I'd be happy to be proved wrong) is that producing good Computer Generated Speech on low profile devices like MP3 players is quite hard whereas the implementation of AudioText frames is really simple.

Chris

____________________________________________ 

Chris Newell 
Lead Technologist 
Technology Group
BBC New Media & Technology
Kingswood Warren, Woodland Way, Tadworth
Surrey  KT20 6NP   UK

Tel:    +44 (0)1737 839659
Fax:    +44 (0)1737 839665
mailto:chris.newell at rd.bbc.co.uk
   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20060614/900b1348/attachment.html>

From iontodirel at yahoo.co.uk  Tue Jun  6 14:46:53 2006
From: iontodirel at yahoo.co.uk (Ion Todirel)
Date: Tue, 6 Jun 2006 21:46:53 +0000 (GMT)
Subject: [ID3 Dev] ID3v2 Tag Reader/Writer
In-Reply-To: <28428.195.91.54.86.1149619191.squirrel@webmail-4.domains.sk>
Message-ID: <20060606214653.28375.qmail@web86902.mail.ukl.yahoo.com>

hey,
 
i want a .NET component that supports "some" of the ID3v2 tag, and able to read/write tags. At least a COM component.
 
Thanks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20060606/26440bf1/attachment.html>

From jid3 at blinkenlights.org  Wed Jun  7 11:42:22 2006
From: jid3 at blinkenlights.org (Paul Grebenc)
Date: Wed, 7 Jun 2006 14:42:22 -0400 (EDT)
Subject: [ID3 Dev] I want to make my Java API OpenSource
In-Reply-To: <44871AF2.6020304@fastmail.fm>
References: <52852.195.91.54.86.1149616225.squirrel@webmail-4.domains.sk>
 <4da424620606070554l297ac2c3g794540ef99a1f141@mail.gmail.com>
 <44871AF2.6020304@fastmail.fm>
Message-ID: <Pine.LNX.4.63.0606071431370.24588@localhost.localdomain>

On Wed, 7 Jun 2006, Paul Taylor wrote:

> Tagging Library (https://jaudiotagger.dev.java.net/). As Tom said LGPL means 
> that anybody who modifies the library must release the changes they have made 
> , but they dont have to release any other source code that just uses the 
> library. So if I make an enhancement to the library I need to let you know

One issue with the LGPL though, which might be of concern, is that if you 
use an LGPL library, it is possible that users of your software have a 
right to reverse engineer your code if necessary to upgrade to a new 
version of the library.  So if you release a closed-source application 
that uses v1 of an LGPL library, your users may have the right to reverse 
engineer your software if necessary in order to get your application to 
work with v2 of the LGPL library.

 From http://www.gnu.org/licenses/lgpl-java.html:

"FSF's position has remained constant throughout: the LGPL works as 
intended with all known programming languages, including Java. 
Applications which link to LGPL libraries need not be released under the 
LGPL. Applications need only follow the requirements in section 6 of the 
LGPL: allow new versions of the library to be linked with the application; 
and allow reverse engineering to debug this."

Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From marvmove at hotmail.com  Wed Jun  7 11:54:45 2006
From: marvmove at hotmail.com (Marvin Hamlet)
Date: Wed, 07 Jun 2006 18:54:45 +0000
Subject: [ID3 Dev] Is it possible to 'lock' ID3 tags?
Message-ID: <BAY103-F966E0B12488D7FE4E7896D68A0@phx.gbl>

Hello everyone.

As the subject suggests, I'm wondering if it is possible to produce a tag 
editor that somehow locks the ID3 tags, so that once written, the 
information cannot be overwritten. I suspect not, but if any group of people 
might know for certain, I feel sure it is amongst the members of this 
community.

I know it's possible to 'wrap & hide' the mp3 file in some way, but that is 
not the ideal solution I'm looking for. I'm hoping that it is possible to 
lock the ID3 metadata itself - though I have my concerns that some methods 
may render the file unreadable to other players and editors.

I'd really appreciate some feedback on this. Thanks in advance.

_________________________________________________________________
The new MSN Search Toolbar now includes Desktop search! 
http://join.msn.com/toolbar/overview


---------------------------------------------------------------------
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 Jun 21 08:06:53 2006
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Wed, 21 Jun 2006 16:06:53 +0100
Subject: [ID3 Dev] Accessibilty extension draft is posted
In-Reply-To: <200606161623.03066.wheeler@kde.org>
References: <448CCCD4.4060001@northpb.com>
 <200606141426.04845.wheeler@kde.org>
 <6.2.0.14.2.20060614133403.025164f0@pop3>
 <200606161623.03066.wheeler@kde.org>
Message-ID: <6.2.0.14.2.20060621120008.026cbcf8@pop3>

Scott,
At 15:23 16/06/2006, Scott Wheeler wrote:
>On Wednesday 14 June 2006 16:02, Chris Newell wrote:
>> >Two things that jump out to me as bits that won't work:
>> >
>> >- You can't embed arbitrary audio into an ID3 tag and expect for it to be
>> >decoded properly since it messes up synching.  For instance, with MPEG
>> > audio, when you hit an MPEG synch frame, the audio player will just play
>> > the stuff there like it's the first bit of audio content.  The rest of
>> > the tag will be ignored.
>>
>> I discovered this to my cost when trying out a prototype:-) However, using
>> the ID3v2 unsynchronisation scheme appeared to solve this.
>>
>> The draft proposal recommends that unsynchronisation is applied but perhaps
>> this should be a mandatory if AudioText frames are present.
>
>Unfortunately MPEG is the simple case.  Granted, the primary target of ID3 
>files is MPEG audio, but they are used for some other things (FLAC comes to 
>mind).  The absence of explicit unsynchronization for non-MPEG formats 
>usually doesn't cause problems just because statistically it's not likely to 
>accidentally have a properly formatted header.  However, if you're 
>intentionally putting them in there, it could be problematic.

I'd be happy for the proposal to state that it is only appropriate for file formats that are compatible with the ID3 unsynchronisation scheme. The problem space is too big otherwise.

>Also, speaking of synchs, the image in the draft shows a synch safe integer 
>for the size, which would be really strange in an ID3v2.3 tag since they're 
>not used there.

OK - as it's not explicitly stated to be an v2.4 tag it would be better to omit the "sync safe" label.

>> >- Equivalent Frame ID doesn't work for frames that allow multiple
>> > instances of the same frame.
>>
>> Couldn't you use multiple instances of AudioText frame with the same
>> Equivalent Frame ID?
>>
>> It's true that in the current proposal you cannot assume a one-to-one
>> relationship between a specific text frame and a specific AudioText frame
>> if there are multiple instances with the same Equivalent Frame ID and
>> language code.
>>
>> Would a satisfactory solution be to imply this relationship (if required)
>> from the order in which they are found within the frame?
>
>There's no guarantee that external taggers don't reorder frames when they 
>write tags, so a third party tool just updating the tag would break things.

OK. An alternative solution could be to include a "Description" field so that each AudioText frame is uniquely associated with an equivalent text frame by a combination of:

   Frame ID
   Language Code
   Description   

For frames where only one instance is permitted there is generally no "Description" field and therefore this would be set to $00.

>With all this I don't mean to be overly negative -- just kind of playing 
>devil's advocate from an engineering perspective...

No problem, the scrutiny is appreciated.

Chris


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From id3v2 at audiott.com  Tue Jun  6 10:50:25 2006
From: id3v2 at audiott.com (Michal Vician)
Date: Tue, 6 Jun 2006 19:50:25 +0200 (CEST)
Subject: [ID3 Dev] I want to make my Java API OpenSource
Message-ID: <52852.195.91.54.86.1149616225.squirrel@webmail-4.domains.sk>

Hi!

Maybe some of you know me. I've been for few months very busy because of
school leaving exams. Fortunately, I passed all of them without any
problems and now I have time for things I relly like - programming :-)

Maybe you know freeware AudioTT which I have wrote. Now I want to publish
my Java API that can handle almost everything related to MP3 and ID3 tags
(using this API you can gain information about MP3 format, manipulate with
ID3 v1/v2.3/v2.4 tag, it supports also new CHAP and CTOC frames ....).

Is there anybody have some experiences with GPL, LGPL... licences, or
anybody who would like to contribute etc.

Just let me know please. I appreciate any help.

Kind regards
Miso

---
Michal Vician
id3v2 at audiott.com
http://www.audiott.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From paul_t100 at fastmail.fm  Wed Jun  7 11:29:06 2006
From: paul_t100 at fastmail.fm (Paul Taylor)
Date: Wed, 07 Jun 2006 19:29:06 +0100
Subject: [ID3 Dev] I want to make my Java API OpenSource
In-Reply-To: <4da424620606070554l297ac2c3g794540ef99a1f141@mail.gmail.com>
References: <52852.195.91.54.86.1149616225.squirrel@webmail-4.domains.sk> <4da424620606070554l297ac2c3g794540ef99a1f141@mail.gmail.com>
Message-ID: <44871AF2.6020304@fastmail.fm>

Personally I would recommend LGPL which is what I have used for my Java 
ID3 Tagging Library (https://jaudiotagger.dev.java.net/). As Tom said 
LGPL means that anybody who modifies the library must release the 
changes they have made , but they dont have to release any other source 
code that just uses the library. So if I make an enhancement to the 
library I need to let you know about it, this benefits everyone. If I 
decide to write another application that uses your library but dont want 
to release the source code I can , this means you get input from a wider 
pool of people and companies. The edge cases don't appear to Java  LGPL 
and to be honest would you go to the trouble of taking somebody to court 
if they did break the license agreement.

The trouble with the GPL is it is very restrictive, basically it says 
the library can only be used by other open source libraries. In practise 
the situation is probably worse, unscrupulous individuals/companies can 
see your code but will use it in closed source applications and as so 
not too bring attention to themselves will not inform you of any 
improvement s they do make.

In this particular scenerio if you made your library LGPL I could use 
elements of your library in mine and vice versa creating some synergy 
for the benefit of both projects. However if you made it GPL I could not 
because I would have to make my library GPL as well.

BTW I recommend www.java.net for hosting your project, they provide a 
number of useful tools such as source control,forums,mailing lists .. 
and because the it is purely java based and hosted by SUN there are alot 
of users of the site with good knowledge to help improve your project.

Paul

Tom Sorensen wrote:

> To clarify what Scott said a bit, here's what happens if you release
> your library under X license (loosely):
>
> BSD/MIT (very similar): They are not required to publish any source,
> only to acknowledge your library and indicate that you wrote it, not
> them.
> LGPL: As above, but they do have to publish changes they make to your 
> source.
> GPL: As above, plus they have to publish all of their own source code,
> even if they link to it dynamically.
>
> Note that LGPL is of questionable legal standing; it's never been
> tested and there's a lot of weird "edge" cases (although I'm unsure
> that they apply to Java). Both the BSD/MIT licenses and the GPL are
> court tested (in the US at least) and solid.
>
> There are many, many other OSS licenses as well, but those four are
> the big ones, and most other licenses are similar in nature to one of
> them.
>
> On 6/6/06, Michal Vician <id3v2 at audiott.com> wrote:
>
>> Hi!
>>
>> Maybe some of you know me. I've been for few months very busy because of
>> school leaving exams. Fortunately, I passed all of them without any
>> problems and now I have time for things I relly like - programming :-)
>>
>> Maybe you know freeware AudioTT which I have wrote. Now I want to 
>> publish
>> my Java API that can handle almost everything related to MP3 and ID3 
>> tags
>> (using this API you can gain information about MP3 format, manipulate 
>> with
>> ID3 v1/v2.3/v2.4 tag, it supports also new CHAP and CTOC frames ....).
>>
>> Is there anybody have some experiences with GPL, LGPL... licences, or
>> anybody who would like to contribute etc.
>>
>> Just let me know please. I appreciate any help.
>>
>> Kind regards
>> Miso
>>
>> ---
>> Michal Vician
>> id3v2 at audiott.com
>> http://www.audiott.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
>> For additional commands, e-mail: id3v2-help at id3.org
>>
>>
>
> ---------------------------------------------------------------------
> 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 Jun 22 02:07:23 2006
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Thu, 22 Jun 2006 10:07:23 +0100
Subject: [ID3 Dev] Accessibilty extension draft is posted
In-Reply-To: <200606211816.48302.wheeler@kde.org>
References: <448CCCD4.4060001@northpb.com>
 <200606161623.03066.wheeler@kde.org>
 <6.2.0.14.2.20060621120008.026cbcf8@pop3>
 <200606211816.48302.wheeler@kde.org>
Message-ID: <6.2.0.14.2.20060622092259.02619588@pop3>

Scott,
At 17:16 21/06/2006, you wrote:
>On Wednesday 21 June 2006 17:06, Chris Newell wrote:
>> For frames where only one instance is permitted there is generally no
>> "Description" field and therefore this would be set to $00.
>
>That doesn't work, for instance, with the W... frames.  (i.e. WOAR)  Search 
>through the frames spec for "more than one" and you'll see that there are a 
>variety of formats used for frames that allow multiple instances.

The original proposal was really intended for frames that carry human readable text strings as I didn't think it would be very useful to read out things like URLs.

>It also doesn't address the problem of updating (when the audio and text go 
>out of synch) mentioned in my last mail.

I see your point, although you can break most things with an authoring tool if you try hard enough!

I'm warming to the idea of a lookup table mapping strings to audio clips, since this would support any frame type and solves the multiple instance problem neatly. How about using a hash code approach to map strings to audio clips?

Chris


---------------------------------------------------------------------
To unsubscribe, e-mail: id3v2-unsubscribe at id3.org
For additional commands, e-mail: id3v2-help at id3.org


From wheeler at kde.org  Wed Jun 14 05:26:03 2006
From: wheeler at kde.org (Scott Wheeler)
Date: Wed, 14 Jun 2006 14:26:03 +0200
Subject: [ID3 Dev] Accessibilty extension draft is posted
In-Reply-To: <448CCCD4.4060001@northpb.com>
References: <448CCCD4.4060001@northpb.com>
Message-ID: <200606141426.04845.wheeler@kde.org>

On Monday 12 June 2006 4:09, Dan O'Neill wrote:
> Chris Newell's proposal for an Accessibility frame has been posted.
>
> Abstract
>
> This document describes an extension which makes ID3v2 metadata
> accessible to the visually impaired. It may also be useful for audio
> players which have limited display capabilities. A new frame type is
> proposed that carries an audio clip which can provide a verbal
> expression of the textual information carried by any other ID3v2 frame.
>
> http://www.id3.org/id3v2-accessibility-1.0.html
>
> Links to the document are kept on the developers page.
>
> http://www.id3.org/develop.html

Two things that jump out to me as bits that won't work:

- You can't embed arbitrary audio into an ID3 tag and expect for it to be 
decoded properly since it messes up synching.  For instance, with MPEG audio, 
when you hit an MPEG synch frame, the audio player will just play the stuff 
there like it's the first bit of audio content.  The rest of the tag will be 
ignored.

- Equivalent Frame ID doesn't work for frames that allow multiple instances of 
the same frame.  You also might want to consider if you want to do anything 
special for frames that contain multiple, distinct strings.

(I must say that I'm somewhat sceptical of the uses of the extension in 
general, vs., say, screen readers, but I'll take the time to read the paper 
you just sent later on.)

-Scott

-- 
The world is full of magical things patiently waiting for our wits to grow 
sharper. 
--Bertrand Russell

---------------------------------------------------------------------
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 Jun 22 03:09:19 2006
From: chris.newell at rd.bbc.co.uk (Chris Newell)
Date: Thu, 22 Jun 2006 11:09:19 +0100
Subject: [ID3 Dev] Accessibilty extension draft is posted
In-Reply-To: <200606221142.56676.wheeler@kde.org>
References: <448CCCD4.4060001@northpb.com>
 <200606211816.48302.wheeler@kde.org>
 <6.2.0.14.2.20060622092259.02619588@pop3>
 <200606221142.56676.wheeler@kde.org>
Message-ID: <6.2.0.14.2.20060622105436.02618b10@pop3>

Scott,
At 10:42 22/06/2006, you wrote:
>On Thursday 22 June 2006 11:07, you wrote:
>> I'm warming to the idea of a lookup table mapping strings to audio clips,
>> since this would support any frame type and solves the multiple instance
>> problem neatly. How about using a hash code approach to map strings to
>> audio clips?
>
>What would the hash be for?

To avoid string duplication and to provide an easy lookup mechanism. My background is in digital broadcast so I tend to be rather mean about bits.

>If you mean to avoid string duplication, I think just duplicating the text 
>would be easier to implement and easier to spec.  In terms of sizes, the text 
>"Rolling Stones" including null termination is 15 bytes.  A two second, 96 
>kb/s, 22050 kHz, mono mp3 is going to take around 5000 bytes.  Saving 7 bytes 
>by using an 8 byte hash instead probably wouldn't be worth it, plus it'd make 
>the files harder to read with a hex editor.  :-)

If string duplication and lookup are not issues then the solution can be very simple.

The next question which comes to mind is do need a new frame type or can we use the "GEOB" frame in some way?

Chris
  
____________________________________________ 

Chris Newell 
Lead Technologist 
Technology Group
BBC New Media & Technology
Kingswood Warren, Woodland Way, Tadworth
Surrey  KT20 6NP   UK

Tel:    +44 (0)1737 839659
Fax:    +44 (0)1737 839665
mailto:chris.newell at rd.bbc.co.uk
   
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.id3.org/pipermail/id3v2/attachments/20060622/45105914/attachment.html>