similar to: Re: proposal1

A month or two ago I sent an email to this list proposing to expand the list of "standard" tags for Ogg Vorbis. No tag would be required, but if you wanted to encode certain types of information about a file, you could use a standard tag. I went through the whole discussion, and revised my proposal in light of all the comments from everyone. Here is the updated proposal. This

I mentioned sub-tagging in an earlier post. Here's a more in-depth mail on what i thought of. One of the debates going on here are whether ARTIST is worthy of life. Another is whether the average user will bother filling in the detailed info Jonathan wants. Of course, all tags are optional, but nevertheless we should have a tagging-system that pleases _the_users_, that is, everybody: 1.

On Tuesday 11. September 2007 02:54:19 David K. Gasaway wrote: > On 11 Sep 2007 at 2:17, Daniel Aleksandersen wrote: > (BTW, you replied to me personally .. just in case that wasn't > intentional) Oh yes, sorry about that. > > On Tuesday 11. September 2007 02:11:01 David K. Gasaway wrote: > > > This things are easily solved with vorbis comments ... Provided you >

-----BEGIN PGP SIGNED MESSAGE----- [ Sorry for sending this twice; I sent it to the vorbis-dev list by mistake. ] The ALBUM, ARTIST, TITLE, and TRACKNUMBER tags aren't sufficient for classical music. MP3 muffed it, but since Vorbis is so flexible, I'd like to propose that ogg123 recognize and display the following optional tags, instead of giving an error message that it doesn't

-----BEGIN PGP SIGNED MESSAGE----- [ Sorry for sending this twice; I sent it to the vorbis-dev list by mistake. ] The ALBUM, ARTIST, TITLE, and TRACKNUMBER tags aren't sufficient for classical music. MP3 muffed it, but since Vorbis is so flexible, I'd like to propose that ogg123 recognize and display the following optional tags, instead of giving an error message that it doesn't

Jonathan added to the proposal the following definition: ARTIST for information to be displayed on systems with limited display capabilities. it is not a replacement for the ENSEMBLE and PERFORMER tags, but typically will summarize them. As I understand the aim is to provide more compatibility with players (especially portable) that are so dumb as to display only "ARTIST",

Hi, <p>here's my €0.02 on that topic. First of all, all those new tags are total overkill to be standardized. They're only useful for people who both tag OGG files for a living and listen to classical music only. Imagine what will happen when the Jazz fans, and the Techno fans, and the Rock fans and who knows else demands his very own, customized + standardized set of tags. And

Based on peoples posts to this list, and feedback on IRC (irc.openprojects.net #vorbis) I have updated the original proposal. You can read it here. Please read it before writing any futher questions, comments, or criticisms of the proposal. http://reactor-core.org/~djw/ogg-tags.txt Cheers Jonathan -------------- next part -------------- A non-text attachment was scrubbed... Name: part Type:

I change a lot of my CD to Ogg to be able to listen them easily from my computer (I use foobar, I was used to WMP but it does not support library for Ogg files and plug-ins I found for this where poor) without the need for frequent CD changing. I like my music to be richly tagged. But with classical music CD it is a real pain to tag those files. Typical problems involve: - single CD

I've read through what I think is the entire thread and looked at the standard in its current incarnation (https://reactor-core.org/~djw/ogg-tags.txt). I have only one major problem with the proposed standard at the moment. The existance of both PERFORMER and ENSEMBLE tags. I think this is describing the same type of data (ENSEMBLE = thing that performed the music, PERFORMER = thing that

I've read through what I think is the entire thread and looked at the standard in its current incarnation (https://reactor-core.org/~djw/ogg-tags.txt). I have only one major problem with the proposed standard at the moment. The existance of both PERFORMER and ENSEMBLE tags. I think this is describing the same type of data (ENSEMBLE = thing that performed the music, PERFORMER = thing that

okay all i want to do now is just DELETE any and all comments from a file. here's what I do: // open the file and get access to comments vcedit_open(i_vcStateP, i_fileP); i_commentsP = vcedit_comments(i_vcStateP); // now delete all existing comments vorbis_comment_clear(i_commentsP); <-- is this the correct way?? vorbis_comment_init(i_commentsP); <-- do i need to do this since

Some suggestions for the recommendations on http://reactor-core.org/ogg-tag-recommendations.html: Add in a table of contents. Please. Rename the title to "Vorbis-style Comment Field Recommendations" (change capitalization to taste) to reflect that FLACs and Speex files could be tagged according to this recommendation. Do note that not just Ogg (or, for that matter, .ogg) files can use

Hi, having inspected one of the files found at music.ibiblio.org, I realized that the comments are quite poor or misformatted in the files. I'm telling you, because: 1) I think it's great to have some free music 2) I think the performers deserve to be recognized Generally, I'd put as much as possible into the Vorbis comments. Then you could skip creating these index.html manually:

Hey all. Ok, so I'll stand up and be counted a newbie in this list too (just did the same for the General discussion list). I (once again) read through the archives, especially the ones concerning the comment field. First, I'm not a developer, per se. I'm merely an anal-retentive power user of such things, who likes to have my music archived, and sorted. In reading through the

Silvia Pfeiffer wrote: > Daniel, > > before you step over everything that has been done before, we need to > determine what exactly is the use case for your new specification. > > What concerns metadata, we currently have: > > * vorbiscomment - this is a header at the beginning of a logical > bitstream which has metadata that refers to the complete file; there > is

On Sun, 2 Feb 2003, oddsock wrote: | I have just committed this code to CVS, and here is more information about | it for those interested : This is great! But I have a few wonderings: I'm suprised that the HTTP/GET method of notifying YP servers is still preferred. According to this protocol, we're still limited to essentially title/author, listeners, etc. In other words, we're

Ralph Giles wrote: > On Mon, Sep 10, 2007 at 01:19:05PM +0100, Ian Malone wrote: > >> as artist=(composer) Beethoven), I think cast lists for films present >> a similar problem. There is consistency and indexability to be >> addressed (Ludvig van Beethoven; Beethoven, Ludvig van; >> Beethoven). > > ID3 has a concept of "sort" tags, which provide a

On Mon, Sep 10, 2007 at 01:19:05PM +0100, Ian Malone wrote: > as artist=(composer) Beethoven), I think cast lists for films present > a similar problem. There is consistency and indexability to be > addressed (Ludvig van Beethoven; Beethoven, Ludvig van; > Beethoven). ID3 has a concept of "sort" tags, which provide a string for sorting purposes which is different from the

Here is preliminary patch for fileinfo for xmms plugin. Saving and removing of the tag isn't working. When saving, how handle id3v1, v2? Display and edit more fields (e.g. performer)? How handle genres? Combo with predefined values? -- Miroslav Lichvar -------------- next part -------------- Index: src/plugin_xmms/Makefile.am