IPB

Welcome Guest ( Log In | Register )

75 Pages V  « < 73 74 75  
Reply to this topicStart new topic
foo_discogs, Tags files with information from Discogs
mnogo9
post Jun 20 2015, 21:13
Post #1851





Group: Members
Posts: 2
Joined: 14-June 15
Member No.: 119662



QUOTE (zoomorph @ Jun 14 2015, 21:24) *
Is the clock on your system set correctly? Incorrect clock seems to cause an error from Discogs when configuring OAuth.

Thankyou, zoomorph, for fast answer.
Hmm... Time was correct, but time-sync service was off. I'd enable service - and authorization get successful!
Thank You! smile.gif
Go to the top of the page
+Quote Post
fuffi
post Jun 20 2015, 22:59
Post #1852





Group: Members
Posts: 250
Joined: 10-February 07
From: kölle an rhein
Member No.: 40490



QUOTE (zoomorph @ Jun 15 2015, 22:02) *
QUOTE (zoomorph @ Jun 15 2015, 22:02) *
QUOTE (zoomorph @ Jun 15 2015, 01:26) *
7) Did you see the "DISCOGS_CREDIT_FEATURING" tag? It seems to be what you're requesting.
Yes, but it did not work here with the mentioned release. That was the reason, I wrote about my unsuccessful attempts. I defaulted the settings but did not get a tag.
I see.. because the credits are "Featuring [...]", they don't match "Featuring". I'm sure this can be solved. For one, replacing $multi_strcmp() with $multi_strstr() should work, but this might accept credits that you don't want, such as "Whatever [Featuring]". Another solution would be to use $multi_left() to get the left 9 characters before doing the $multi_strcmp(). This would accept anything that starts with "Featuring". Another solution, maybe the best?, would be to expose another tag, say CREDIT_TYPE ("Featuring") vs. CREDIT_NAME ("Featuring [Unlisted]").

Thanks for explanation and suggestions, I did'nt understood the last suggestion and how it can be achieved.
I will check that later, atm I don't have time to experiment ;-) I'll just use the old component, which worked in 100% for the featuring-tag.
In fact, I cannot remember, when or why it not worked exctracting the featuring artists from the releases. Maybe this was before the track index were invented or just old releases? dunno.

QUOTE (zoomorph @ Jun 15 2015, 22:02) *
QUOTE (fuffi @ Jun 15 2015, 19:50) *
QUOTE (zoomorph @ Jun 15 2015, 01:26) *
1) Update tags is a problem since it requires automatically matching files to the tracklist. Old method was unreliable, new method is better but still not perfect. I haven't decided what to do with it yet.
What are you technicially thinking about, when u try to decide?
Haven't decided how to balance accuracy (make sure that you're updating the right track from the tracklist) vs. automation (no requiring any manual work).

One possibility is to make "update tags" automated whenever it can match tracks, but fall back to manual confirmation if tracks can't be matched with enough accuracy.

Then, there is the question of how to match tracks. Traditionally, it used the track number and just went with it. More recently, it uses the track index in the Discogs tracklist (untested, may not work lol) which is slightly more reliable. Another possibility (only works ~50% of the time) is automatic matching via durations. So, a combination of various methods could be used to try to automatically match files to the tracklist....

Ok. Like the above subject, I never had problems with updating tracks with the old component. (But I never update track-title or album name or artists, so maybe, I never recognized the problems...just updated the "background" informaiton, like all the discoGS tags which facillitate the searching inside my music database via foobar)

Only, when autoamtic matching with track-length was activated, then the old component had a 70% failure in matching the correct tracks (for various reasons, which I'm not gonna type down now).

Just for curiosity, do you have an example release, where the old coding for updating tracks does not work?

For me, I would prefer to easily switch from the newcoming version of updating tracks to the old one. Maybe via an user chosen config-setting, if applicable.

Moving around or drag'n'drop the tracks would be an acceptable situation too (assumed, the user knows where to move the tracks).
Maybe marking tracks, which the component is not sure about with a diferent colour?
Or popping up a new window where the user can choose from n different sortings the component had gathered ? hmmm...actually, I understand, why u did not concluded this subject ;-)


Go to the top of the page
+Quote Post
zoomorph
post Jun 22 2015, 03:41
Post #1853





Group: Developer
Posts: 182
Joined: 16-August 14
Member No.: 117002



QUOTE (fuffi @ Jun 20 2015, 22:59) *
Thanks for explanation and suggestions, I did'nt understood the last suggestion and how it can be achieved.
I will check that later, atm I don't have time to experiment ;-) I'll just use the old component, which worked in 100% for the featuring-tag.
In fact, I cannot remember, when or why it not worked exctracting the featuring artists from the releases. Maybe this was before the track index were invented or just old releases? dunno.

Yes, the old version worked fine. So will the new version, it's just a question of getting the right formatting string. In the meanwhile, of course you can continue to use the old version.

QUOTE (fuffi @ Jun 20 2015, 22:59) *
Ok. Like the above subject, I never had problems with updating tracks with the old component. (But I never update track-title or album name or artists, so maybe, I never recognized the problems...just updated the "background" informaiton, like all the discoGS tags which facillitate the searching inside my music database via foobar)

Only, when autoamtic matching with track-length was activated, then the old component had a 70% failure in matching the correct tracks (for various reasons, which I'm not gonna type down now).

Just for curiosity, do you have an example release, where the old coding for updating tracks does not work?

For me, I would prefer to easily switch from the newcoming version of updating tracks to the old one. Maybe via an user chosen config-setting, if applicable.

Moving around or drag'n'drop the tracks would be an acceptable situation too (assumed, the user knows where to move the tracks).
Maybe marking tracks, which the component is not sure about with a diferent colour?
Or popping up a new window where the user can choose from n different sortings the component had gathered ? hmmm...actually, I understand, why u did not concluded this subject ;-)

The old method of updating tags would likely continue to work in the majority of cases, although new features like parsing Disc # and hidden tracks make it more difficult. The main issue is of accuracy. If you're OK with, maybe, 99% accuracy and 1% silent mistakes, then the old version is OK. If, like me, you desire as much accuracy as possible, then I think we can do better and that the old version is not good enough.

Examples where the old version method would match tracks wrongly when updating tags:
- Order of tracks was changed on Discogs database
- Track # tag was changed manually by user
- Hidden track was treated as a non-hidden track
- Disc # doesn't match the disc # by the new parsing method

The issue is of accuracy. Using the old version method, maybe 99% would be correct but 1% silently matched to the wrong tracks on the tracklist. Maybe some users are OK with that, but I desire to do better. But I haven't figured out how to do better, yet, so until then it will be broken. :-)
Go to the top of the page
+Quote Post
zoomorph
post Jun 29 2015, 03:28
Post #1854





Group: Developer
Posts: 182
Joined: 16-August 14
Member No.: 117002



I'm currently thinking of removing "Update Tags" altogether and replacing it with the following options:

1. Skip "find release" dialog if DISCOGS_RELEASE_ID tag is already present.
2. Skip "release" dialog if files are successfully matched to Discogs tracklist.

So, to update tags would be basically the same as to write tags, with these options enabled. Maybe I'd leave "Update Tags" in foo_discogs, but it would just enable those two options behind the scenes and then do the same thing as "Write Tags".

Writing tags would sort all selected files by release id, if present, and operate on them in groups.

Additionally, I'm thinking of adding more options on how to match files to the tracklist: duration, track number, title/artist metadata tags, assume sorted order. These methods can be enabled or disabled, and if any give conflicting results, or none of the enabled methods give valid results, then matching tracks would fail. If matching tracks fails, the "release" dialog would necessarily be shown for review.

This will be another major change to how the plugin currently works with respect to writing & updating tags, so it will take some time to implement.

Finally, I am thinking of removing some other features like selecting style/genre on the "release" dialog. My thought is that if it can't be automated or controlled via a tag formatting string, and info needs to be manually changed by the user, then it should probably be done outside of foo_discogs altogether.
Go to the top of the page
+Quote Post
simcut
post Jul 2 2015, 00:54
Post #1855





Group: Members
Posts: 21
Joined: 10-July 12
Member No.: 101309



QUOTE (zoomorph @ Jun 29 2015, 03:28) *
Finally, I am thinking of removing some other features like selecting style/genre on the "release" dialog. My thought is that if it can't be automated or controlled via a tag formatting string, and info needs to be manually changed by the user, then it should probably be done outside of foo_discogs altogether.


Hi Zoo, really appreciate all you do with this plugin, but please dont remove the ability to change the genre/style on the release dialog, it's a real timesaver having it editable in the release dialog.

Cheers
Go to the top of the page
+Quote Post
romprod
post Jul 11 2015, 14:46
Post #1856





Group: Members
Posts: 2
Joined: 11-July 15
Member No.: 119884



Hi,

Great plugin so far.

Is it somehow possible that I can set the search results to show the amount of tracks in each result?

Seems the majority of the albums that I have in my collection seem to have extra's in them, so they don't match the basic albums.

At the moment to use this plugin i would have to check each version of the discog result to check for the correct album.

Thanks.
Go to the top of the page
+Quote Post
fuffi
post Jul 11 2015, 20:19
Post #1857





Group: Members
Posts: 250
Joined: 10-February 07
From: kölle an rhein
Member No.: 40490



QUOTE (romprod @ Jul 11 2015, 15:46) *
Is it somehow possible that I can set the search results to show the amount of tracks in each result?

This is something, I always wanted to have too ;-)
so +1 if the DG-Api supports that.
Go to the top of the page
+Quote Post
fuffi
post Jul 11 2015, 23:07
Post #1858





Group: Members
Posts: 250
Joined: 10-February 07
From: kölle an rhein
Member No.: 40490



QUOTE (simcut @ Jul 2 2015, 01:54) *
QUOTE (zoomorph @ Jun 29 2015, 03:28) *
Finally, I am thinking of removing some other features like selecting style/genre on the "release" dialog. My thought is that if it can't be automated or controlled via a tag formatting string, and info needs to be manually changed by the user, then it should probably be done outside of foo_discogs altogether.
Hi Zoo, really appreciate all you do with this plugin, but please dont remove the ability to change the genre/style on the release dialog, it's a real timesaver having it editable in the release dialog.

yes, from here too, this is -not very often used, but when used- a real cool feature. removing it would not lead to a more userful component, I think.
The great advantage of this feature is to quickly add some information to the tagged files in just one go with the DiscoGS tagging.

Please don't remove it. Or maybe I did not understood why it can't be automated?
Go to the top of the page
+Quote Post
dantheham
post Jul 11 2015, 23:57
Post #1859





Group: Members
Posts: 1
Joined: 11-July 15
Member No.: 119888



I can't get discogs to tag anything nor can I get freedb to tag anything.

Bare in mind i am new to foobar, discogs, freedb, to this forum and I havn't been able to tag anything so do not understand fully understand what these taggers can do nor what the correct result looks like. please assume I only know plain english and don't know any foobar or audiophile terminology because i probably do.

All I am trying to do is set foobar or discogs (whichever fits) up to automatically rename/retag all my music with correct artist, song name, album, year, track number, artist and album art and change all this in my source folder also and correct my folder structure or if this is not possible find out how to do this with the least amount of effort.

I have the latest foobar release

Freedb:

I right click on all music in album list, go to tagging get tags from freedb. I get an error message that it can't find any tags fro anything.

when i choose individual albums it does the same or shows me a box to choose selections from. the selections are always completely unrelated to anything in the song or artist name.

sometimes often non english european names when almost all of my music is in english.

the latest discogs install: right clicking on anything going to tagging then to discogs brings up a list with everything greyed out apart from write tags, edit tag mapping and configuration. if i use the write tags function then search for the correct artist it brings an error message.

"Authorization Failed (401) [Is OAuth working?] - (url: http://api.discogs.com/database/search)"

When i first installed discogs it asked me to register with the website and get a code and then told me "oauth" is working.

a google search or youtube search or wikipedia search for most of my music could tell me all the information I need to tag so why can't a dedicated database figure it out or is just the programming in discogs and foobar?

all the setting for both are on the default apart from the "oauth" information that they prompted me and told me what to do. both foobar and discogs are updated

the files are mostly all named with the correct artist and song and album. they may contain extra stuff in the title and not be formatted in the "correct" way but all the information is there and the task should be pretty fucking simple for a tagger.

I switched to using foobar from itunes cus it seamed more functional than itunes. if i have to manually enter tagging info I would let the extra functionality of this go and go back to itunes cus itunes can tag everything how I want even if it is limited in so many ways.

all my music is downloaded rather than from cds, perhaps because they are missing the track numbers it is not working. track numbers should be pretty simple for a tagger given the correct artist album and song name info to work with.

itunes can do what i want can foobar too?

sorry if this is already posted I couldn't find it with the search bar.

thanks for any advice.

cheers
Go to the top of the page
+Quote Post
zoomorph
post Jul 12 2015, 06:49
Post #1860





Group: Developer
Posts: 182
Joined: 16-August 14
Member No.: 117002



QUOTE (fuffi @ Jul 11 2015, 20:19) *
QUOTE (romprod @ Jul 11 2015, 15:46) *
Is it somehow possible that I can set the search results to show the amount of tracks in each result?

This is something, I always wanted to have too ;-)
so +1 if the DG-Api supports that.

Definitely possible. The problem is that the search results from the API have a limited amount of info (most of it is already shown in the info string on the find_release dialog). To get more information, like the # of tracks for each release, would require an extra API call for every release in the find_release dialog. This would be substantial overhead (extra loading time).
Go to the top of the page
+Quote Post
zoomorph
post Jul 12 2015, 06:54
Post #1861





Group: Developer
Posts: 182
Joined: 16-August 14
Member No.: 117002



QUOTE (dantheham @ Jul 11 2015, 23:57) *
I switched to using foobar from itunes cus it seamed more functional than itunes. if i have to manually enter tagging info I would let the extra functionality of this go and go back to itunes cus itunes can tag everything how I want even if it is limited in so many ways.

foo_discogs is not designed to automatically get tags for your music. It is designed to assist with manually tagging your files using the Discogs database. This will have more precision and accuracy than anything that automatically tags your music, as the latter aren't aware of things like different pressings/versions of the same release, tracks taken from different releases, etc.

I can't speak to what iTunes or freedb do as I don't use them.

In my opinion, foobar2000 is a great music player because of its customizability. But there's always a trade-off between that and ease of use. foobar2000 has many components. I'm not sure if any exist that will automatically tag your music files for you. I'm sure that there are plenty of 3rd party applications that can be used to do it.
Go to the top of the page
+Quote Post
fuffi
post Jul 12 2015, 09:12
Post #1862





Group: Members
Posts: 250
Joined: 10-February 07
From: kölle an rhein
Member No.: 40490



QUOTE (zoomorph @ Jul 12 2015, 07:49) *
QUOTE (fuffi @ Jul 11 2015, 20:19) *
QUOTE (romprod @ Jul 11 2015, 15:46) *
Is it somehow possible that I can set the search results to show the amount of tracks in each result?
This is something, I always wanted to have too ;-)so +1 if the DG-Api supports that.
Definitely possible. The problem is that the search results from the API have a limited amount of info (most of it is already shown in the info string on the find_release dialog). To get more information, like the # of tracks for each release, would require an extra API call for every release in the find_release dialog. This would be substantial overhead (extra loading time).

That sounds like it should/could be an option which is deactivated by default and must be activated in the preferences of the compontent by the user.
Or, -which is "more work" for the user, but will safe bandwith and overhead each time- must be requested with a click on the "get # of tracks"-button, which will be only visible, when the first datablock is retrieved and shown.
this way, every user can decide, if he needs that additional data and the DG-Database is not overstrained by each search of the component.
don't know, if the idea with the second-button will be feasible or intuitive...
Go to the top of the page
+Quote Post
Grilinctus
post Jul 12 2015, 11:08
Post #1863





Group: Members
Posts: 2
Joined: 6-February 12
Member No.: 96966



Thanks for this! There seem to be so many moving parts involved; it’s impressive how well the plugin works. Would it be possible to make the search window resizable (right now it seems to be locked at a very small size) and to allow moving multiple tracks up/down at once when tagging an album (right now the buttons have no effect if more than one track is selected)?
Go to the top of the page
+Quote Post
zoomorph
post Jul 16 2015, 00:58
Post #1864





Group: Developer
Posts: 182
Joined: 16-August 14
Member No.: 117002



QUOTE (fuffi @ Jul 12 2015, 09:12) *
QUOTE (zoomorph @ Jul 12 2015, 07:49) *
QUOTE (fuffi @ Jul 11 2015, 20:19) *
QUOTE (romprod @ Jul 11 2015, 15:46) *
Is it somehow possible that I can set the search results to show the amount of tracks in each result?
This is something, I always wanted to have too ;-)so +1 if the DG-Api supports that.
Definitely possible. The problem is that the search results from the API have a limited amount of info (most of it is already shown in the info string on the find_release dialog). To get more information, like the # of tracks for each release, would require an extra API call for every release in the find_release dialog. This would be substantial overhead (extra loading time).

That sounds like it should/could be an option which is deactivated by default and must be activated in the preferences of the compontent by the user.
Or, -which is "more work" for the user, but will safe bandwith and overhead each time- must be requested with a click on the "get # of tracks"-button, which will be only visible, when the first datablock is retrieved and shown.
this way, every user can decide, if he needs that additional data and the DG-Database is not overstrained by each search of the component.
don't know, if the idea with the second-button will be feasible or intuitive...

I got a prototype of that working:
http://i.imgur.com/SLFqTSF.png

Still needs some work before public release. The overhead for loading extra data for every release will make it impractical to include such information, IMO.
Go to the top of the page
+Quote Post
fuffi
post Jul 16 2015, 08:16
Post #1865





Group: Members
Posts: 250
Joined: 10-February 07
From: kölle an rhein
Member No.: 40490



8-)
I'm very excited!
Screenshot looks promising to me.
Also the sneakpreview of the settings window show some nice things!
keep up the good work!! ;-)

Go to the top of the page
+Quote Post
alexinc
post Jul 16 2015, 09:57
Post #1866





Group: Members
Posts: 100
Joined: 12-February 08
Member No.: 51251



looks great!
Go to the top of the page
+Quote Post
romprod
post Jul 17 2015, 23:41
Post #1867





Group: Members
Posts: 2
Joined: 11-July 15
Member No.: 119884



QUOTE (zoomorph @ Jul 15 2015, 23:58) *
QUOTE (fuffi @ Jul 12 2015, 09:12) *
QUOTE (zoomorph @ Jul 12 2015, 07:49) *
QUOTE (fuffi @ Jul 11 2015, 20:19) *
QUOTE (romprod @ Jul 11 2015, 15:46) *
Is it somehow possible that I can set the search results to show the amount of tracks in each result?
This is something, I always wanted to have too ;-)so +1 if the DG-Api supports that.
Definitely possible. The problem is that the search results from the API have a limited amount of info (most of it is already shown in the info string on the find_release dialog). To get more information, like the # of tracks for each release, would require an extra API call for every release in the find_release dialog. This would be substantial overhead (extra loading time).

That sounds like it should/could be an option which is deactivated by default and must be activated in the preferences of the compontent by the user.
Or, -which is "more work" for the user, but will safe bandwith and overhead each time- must be requested with a click on the "get # of tracks"-button, which will be only visible, when the first datablock is retrieved and shown.
this way, every user can decide, if he needs that additional data and the DG-Database is not overstrained by each search of the component.
don't know, if the idea with the second-button will be feasible or intuitive...

I got a prototype of that working:
http://i.imgur.com/SLFqTSF.png

Still needs some work before public release. The overhead for loading extra data for every release will make it impractical to include such information, IMO.


Brilliant thankyou!

This will speed up matching releases sooooooooo much.
Go to the top of the page
+Quote Post
fuffi
post Jul 18 2015, 19:29
Post #1868





Group: Members
Posts: 250
Joined: 10-February 07
From: kölle an rhein
Member No.: 40490



Hello,
a small feature request:

while I'm just tagging very long albums with very much titles/files in it, I'd love to have something useful like the number of total tracks on the tracklist side and the total number of files on the files side.
maybe, they change their color to red when they're not equal or some kind of visual indicating that the two sides have unequal number of entries.

while this is simple to check when albums has only <10 tracks on discogs and locally, it is hard to count when there are releases with >30 or >50 tracks. like i.e. 953151

would be a little timesaver. ;-)

EDIT:
added a little mock-up
http://www.bilder-hochladen.net/i/hcyg-46-0aed.png

This post has been edited by fuffi: Jul 18 2015, 19:48
Go to the top of the page
+Quote Post
kl@p
post Jul 23 2015, 23:07
Post #1869





Group: Members
Posts: 4
Joined: 14-April 11
Member No.: 89802



hi, recently updated foo_discogs and i can't authtorize :
QUOTE
(skipped) Error: Authorization Failed (401) [Is OAuth working?] - (url: http://api.discogs.com/oauth/request_token)
[ESCAPE to close]

console log:
QUOTE
foo_discogs: http://api.discogs.com/oauth/request_token...uth_version=1.0
foo_discogs: HTTP error status: HTTP/1.1 401 Unauthorized
foo_discogs: Exception handling: http://api.discogs.com/oauth/request_token...uth_version=1.0

foo_discogs version:
Authors: Michael Pujos (aka bubbleguuum) (v1.32), zoomorph (v1.33+)
Version: 1.55
Compiled: Mar 24 2015

any suggestion?
i don't have firewall & etc.

This post has been edited by kl@p: Jul 23 2015, 23:11
Go to the top of the page
+Quote Post
zoomorph
post Jul 24 2015, 07:02
Post #1870





Group: Developer
Posts: 182
Joined: 16-August 14
Member No.: 117002



Check that your system clock is set right, that seems to be the cause of that error message.
Go to the top of the page
+Quote Post
dumbnumbscum
post Jul 26 2015, 13:36
Post #1871





Group: Members
Posts: 14
Joined: 24-February 15
Member No.: 118715



QUOTE (zoomorph @ Jun 29 2015, 04:28) *
I'm currently thinking of removing "Update Tags" altogether and replacing it with the following options:

[..]

So, to update tags would be basically the same as to write tags, with these options enabled. Maybe I'd leave "Update Tags" in foo_discogs, but it would just enable those two options behind the scenes and then do the same thing as "Write Tags".

I use "Update Tags" to update files in batch. There have been cases where I decided to add a new field to my files using the tag mappings. After I enable "refresh tag on update" for the new field and disable it for all other fields, I can update all files that already have been tagged using foo_discogs by using the "update tags" function using "write only tags update-enabled", but in such a way that it reduces the duration and traffic load.
Although the interface to this update functionality could be improved ( it would be nice for example if the update function would show me what fields will be updated and let me change it if necessary ), I find it a valuable tool.

QUOTE
1. Skip "find release" dialog if DISCOGS_RELEASE_ID tag is already present.

That a good idea, even if you don't remove the "Update Tags" function.

QUOTE
Additionally, I'm thinking of adding more options on how to match files to the tracklist: duration, track number, title/artist metadata tags, assume sorted order. These methods can be enabled or disabled, and if any give conflicting results, or none of the enabled methods give valid results, then matching tracks would fail. If matching tracks fails, the "release" dialog would necessarily be shown for review.

Sounds great.

This post has been edited by dumbnumbscum: Jul 26 2015, 13:56
Go to the top of the page
+Quote Post
fuffi
post Jul 26 2015, 18:12
Post #1872





Group: Members
Posts: 250
Joined: 10-February 07
From: kölle an rhein
Member No.: 40490



QUOTE (dumbnumbscum @ Jul 26 2015, 14:36) *
it would be nice for example if the update function would show me what fields will be updated and let me change it if necessary
I can not imagine a nice, clean and fast way now, to show those information, but that sounds like a great addition! ;-)
+1
Go to the top of the page
+Quote Post
dumbnumbscum
post Jul 27 2015, 17:45
Post #1873





Group: Members
Posts: 14
Joined: 24-February 15
Member No.: 118715





This post has been edited by dumbnumbscum: Jul 27 2015, 17:47
Go to the top of the page
+Quote Post

75 Pages V  « < 73 74 75
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 1st August 2015 - 14:27