Closed GoogleCodeExporter closed 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
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
Original comment by steven.strobe.cc@gmail.com
on 28 Jun 2009 at 4:23
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
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
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:
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
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
Issue 569 has been merged into this issue.
Original comment by reiter.christoph@gmail.com
on 8 Sep 2010 at 9:02
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
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
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
Issue 804 has been merged into this issue.
Original comment by reiter.christoph@gmail.com
on 30 Aug 2011 at 10:35
Issue 926 has been merged into this issue.
Original comment by reiter.christoph@gmail.com
on 6 Mar 2012 at 4:50
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
Original comment by nick.bou...@gmail.com
on 9 Dec 2012 at 1:43
Issue 1179 has been merged into this issue.
Original comment by reiter.christoph@gmail.com
on 14 Jun 2013 at 8:23
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
Is there a hope for this problem to be fixed soon?
Original comment by mic...@donaflor.fr
on 21 Jul 2013 at 11:08
Issue 1434 has been merged into this issue.
Original comment by reiter.christoph@gmail.com
on 30 Jul 2014 at 7:23
bumpity bump - is there a bounty system?
Original comment by hansBKK@gmail.com
on 19 Aug 2014 at 5:12
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
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
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
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
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
(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
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
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
Original issue reported on code.google.com by
mahikeul...@gmail.com
on 10 Nov 2008 at 8:20Attachments: