lebauce / quodlibet

Automatically exported from code.google.com/p/quodlibet
1 stars 0 forks source link

id3 tag: TXXX frame from another software is not displayed by QL #48

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Only TXXX frames prefixed by "QuodLibet::" are displayed by QL into the
properties editor. TXXX such as "FOOBAR::style" or "style" are not displayed.
On the other hand, Foobar2000 and Kid3 display TXXX frames produced by QL.

Please see the attached file which is the id3 part of a mp3 file tagged
with Foobar2000 (open it with an hexa editor).

By the way, it would be nice to have an option in order QL not prefix the
user descriptor by "QuodLibet::".

Original issue reported on code.google.com by mahikeul...@gmail.com on 10 Nov 2008 at 8:20

Attachments:

GoogleCodeExporter commented 9 years ago
I want this fixed by 2.1 but it's not as easy as it seems. Unchanged tags 
should keep
the foobar:: prefix, until QL edits them.

Not prefixing is a recipe for disaster; the TXXX namespace is a trainwreck in 
terms
of what other rippers/taggers dump there (including non-human-readable data).

Original comment by joe.wreschnig@gmail.com on 30 Nov 2008 at 7:27

GoogleCodeExporter commented 9 years ago
Cool. Is there an estimated date for this 2.1 ?

I understand your point about the need to prefix. But I would like to configure 
a
paned browser this way:

genre/style/artist/album

where style is a TXXX frame such as "FOOBAR::style" or "MediaCenter::style" or
"style". How I can do it ?

Congratulations for this incredible software !
Regards,
Michel

Original comment by mahikeul...@gmail.com on 29 Dec 2008 at 12:44

GoogleCodeExporter commented 9 years ago

Original comment by steven.strobe.cc@gmail.com on 28 Jun 2009 at 4:23

GoogleCodeExporter commented 9 years ago
Really annoying thing as I have a 300gb collection of files tagged by 
foobar2000 with
all label, source and etc. custom stuff, but can't use these fields :( Waiting 
for
2.2 with improvements on this side.
Except that (i'm a newbie with quodlibet though) looks like a great software, 
and
best audioplayer/tagger for Ubuntu i managed to try!

Original comment by the.sub....@gmail.com on 29 Oct 2009 at 10:01

GoogleCodeExporter commented 9 years ago
My solution to this is to not prefix... and then, for those who want to avoid 
the
"trainwreck", provide the *option* to restrict which tags are visible, using 
either
an allow or deny policy, or both. This would allow users to add custom tags to 
what
is visible, and this incompatibility between QL and other players would 
disappear.

I personally prefer to see ALL tags (like foobar2000 functionality), and have 
hacked
my QL accordingly.

Original comment by djpha...@gmail.com on 11 Dec 2009 at 4:03

GoogleCodeExporter commented 9 years ago
Still considering if this is the right approach, but for users who did or still 
do
use another tagging program like Foobar to edit their music, this will let the 
user
sort through the trainwreck on their own.

Original comment by steven.strobe.cc@gmail.com on 2 Jan 2010 at 2:30

Attachments:

GoogleCodeExporter commented 9 years ago
How should we know which tags to delete on writing?

(maybe add a new internal tag prefix like "=(T|C)tagname=content", sincs = is 
not
allowed like ~)

Original comment by reiter.christoph@gmail.com on 2 Jan 2010 at 6:20

GoogleCodeExporter commented 9 years ago
Bumping. But we'll definitely take care of this soon after 2.2.

Original comment by steven.strobe.cc@gmail.com on 24 Jan 2010 at 11:05

GoogleCodeExporter commented 9 years ago
Issue 569 has been merged into this issue.

Original comment by reiter.christoph@gmail.com on 8 Sep 2010 at 9:02

GoogleCodeExporter commented 9 years ago
sorry  reiter.christoph, i must have overlooked this issue, thanks for merging.

I have applied the 48-TXXX.patch and its great to see that much tags to edit 
now. Thanks for that, steven@strobe.cc ! :-)

But Some Tags are still missing that i can see in my mid3v2 output, for Exampel 
this:
POPM=Windows Media Player 9 Series=None 255/255
COMM=MusicMatch_Preference='eng'=Excellent
WXXX=http://www.example.com

is not shown in the Tag editor but can be seen in mid3v2.

Can somebody be so kind to point me in the right direction as to how to display 
all the tags recognized by mid3v3?

Thanks, francis :-)

Original comment by francisc...@gmail.com on 15 Sep 2010 at 7:52

GoogleCodeExporter commented 9 years ago
Here are some other examples that i found while going through a few songs:
TLAN=English
USLT=[unrepresentable data] <- [1]
PRIV=WM/Mood=sometext
TXXX=LYRICS=sometext
TKEY=sometext
POPM==2695345412L 255/255

[1] i have read that this is the frame for (unsyncronized) lyrics. is this the 
tag the lyrics plugin would write to? and how can i display the current value 
of that frame?

Thanks in advance, francis

Original comment by francisc...@gmail.com on 15 Sep 2010 at 8:09

GoogleCodeExporter commented 9 years ago
Thanks for the patch. However... I applied the patch and it does indeed expose 
the TXXX fields for me to edit/remove. However, it appears that saving after 
removing TXXX fields does not actually remove them. After saving QL doesn't 
show the tags anymore, but reloading an mp3 shows the tags have no actually 
been removed.

I, also, would like the option to see/edit _all_ tags.

Original comment by thef...@gmail.com on 17 Sep 2010 at 2:43

GoogleCodeExporter commented 9 years ago
Issue 804 has been merged into this issue.

Original comment by reiter.christoph@gmail.com on 30 Aug 2011 at 10:35

GoogleCodeExporter commented 9 years ago
Issue 926 has been merged into this issue.

Original comment by reiter.christoph@gmail.com on 6 Mar 2012 at 4:50

GoogleCodeExporter commented 9 years ago
I don't understand the logic here at all, hiding all custom TXXX fields entered 
by other taggers on this bizarre "train wreck" assumption - what that all our 
MP3 collections are just random garbage from the intertubes?

Personally my files containing dozens of custom frames are meticulously 
maintained, and this limitation prevents me from using what otherwise looks 
like a great tagger.

So to see the raw output of my MP3s I have to use mid3v2, and then come over 
here for my FLACs? Makes no sense at all.

Put in a "show/hide the trainwreck" button, and if you insist on "protecting 
me" from my (only possibly) disorderly tags then make that the default, but do 
let me see my data please!

Original comment by hansBKK@gmail.com on 28 Aug 2012 at 10:07

GoogleCodeExporter commented 9 years ago

Original comment by nick.bou...@gmail.com on 9 Dec 2012 at 1:43

GoogleCodeExporter commented 9 years ago
Issue 1179 has been merged into this issue.

Original comment by reiter.christoph@gmail.com on 14 Jun 2013 at 8:23

GoogleCodeExporter commented 9 years ago
What about people who would only want to *remove* some tags (not add or 
manipulate existing tags)? Would it be possible to have this?

Original comment by rbr...@gmail.com on 14 Jun 2013 at 2:32

GoogleCodeExporter commented 9 years ago
Is there a hope for this problem to be fixed soon?

Original comment by mic...@donaflor.fr on 21 Jul 2013 at 11:08

GoogleCodeExporter commented 9 years ago
Issue 1434 has been merged into this issue.

Original comment by reiter.christoph@gmail.com on 30 Jul 2014 at 7:23

GoogleCodeExporter commented 9 years ago
bumpity bump - is there a bounty system?

Original comment by hansBKK@gmail.com on 19 Aug 2014 at 5:12

GoogleCodeExporter commented 9 years ago
Would be nice to be able to see these generic TXXX tags in QuodLibet, for the 
moment I use deadbeef but Quodlibet has great features and I'd like to use it 
more

Original comment by afz9...@gmail.com on 28 Oct 2014 at 2:38

GoogleCodeExporter commented 9 years ago
Brain dump:

* Get rid of QuodLibet namespace
* TXXX description gets mapped to tag name
* When TXXX tag name is all uppercase load it as lowercase but try to
  convert back to uppercase on write if such a tag exists. This helps with
  foobar2k compat which only writes uppercase tag names, but QL uses
  lowercase for everything.
* We could also include COMM frames using "comment:lang:desc" tag names.
  "comment::desc" -> "comment:desc" in QL
  "comment:lang:" -> "comment:lang:" in QL
  "comment::" -> "comment" in QL
  And try to skip "lang" when some default value.
* We could also map "website:foo" to WXXX:foo, with special cases for
  "website:commercial" mapping to WCOM.

And for keeping things working for existing databases:

1)
a) Version the loading code and save the version the song was loaded with in 
   the DB.
b) When writing take the DB version into account and ignore tags in the file
   which would have been ignored by the version loading the file (don't just
   delete them)

2)
a) When writing a file, safe in the DB the version used.
b) When reloading a file, take into account the logic used to write the file
   based on the version in the DB.

This ignores external changes.. but there is not much we can do here.

Another problem: all our tags are ascii str atm, this might be a good time
to allow unicode there since TXXX can contain non-ascii descriptions.
This could lead to some fallout..

Original comment by reiter.christoph@gmail.com on 21 Jan 2015 at 12:54

GoogleCodeExporter commented 9 years ago
So good to see at least some thinking about this issue.

If there's ever any interop testing required I'd be glad to help. May I suggest 
as targets IMO in order of importance:

MP3Tag, foobar, Picard/MusicBrainz and MediaMonkey

Original comment by hansBKK@gmail.com on 21 Jan 2015 at 4:02

GoogleCodeExporter commented 9 years ago
And good POPM support, especially per-user and supporting conversion between 
the different player-syntaxes would be a nice stretch target 

I know we don't ask much do we 8-)

Original comment by hansBKK@gmail.com on 21 Jan 2015 at 4:08

GoogleCodeExporter commented 9 years ago
Thanks, checking what others do seems like a good idea.

See Issue 1510 for a proposal for handling ratings.

Original comment by reiter.christoph@gmail.com on 21 Jan 2015 at 4:10

GoogleCodeExporter commented 9 years ago
(Meant in a spirit of fun) "Well, duh!"

The source of this flaw in QL is the assumption that anyone would want to 
restrict themselves to one package in maintaining their media.

Interoperability with the other parts of the ecosystem is IMO sine qua non.

Even / especially the 800-lb gorillas like iTunes and windoze. . .

Thanks for your attention to these issues, and of course for all your great 
contributions to the community.

Original comment by hansBKK@gmail.com on 21 Jan 2015 at 7:15

GoogleCodeExporter commented 9 years ago
A simpler alternative to versioning would be to load and display namespaced 
tags as 'Quodlibet::tagname', so users can decide for themselves whether to 
keep namespacing or not. Downside would be users possibly needing to tweak some 
settings to keep QL's behavior the same as it was before, if they don't want to 
re-tag their files. Are there any hard-coded TXXX tag dependencies in QL?

About case-sensitivity, I'd vote for simply down-casing all tags when saving. I 
know that would result in some unnecessary tag churn, but I can't see how that 
would affect users at all sice it only happens when we'd already be writing to 
the file anyway. I'm not strongly against Christoph's proposed algorithm or 
anything, I just think it's likely more complexity than it's worth.

As for allowing non-ASCII tags, I think that should be considered as a separate 
issue, and probably deferred until after the namespacing changes.

Original comment by qjh...@gmail.com on 25 Jan 2015 at 12:03

GoogleCodeExporter commented 9 years ago
Because Google Code is going away [0] we've moved this bug tracker to GitHub.

This issue is now available at

https://github.com/quod-libet/quodlibet/issues/48

In case you are still interested in this issue and have a GitHub account, you
can subscribe to the new issue using the "Subscribe" button on the right hand
side of the page.

[0] http://google-opensource.blogspot.co.at/2015/03/farewell-to-google-code.html

Original comment by reiter.christoph@gmail.com on 16 Mar 2015 at 11:17