Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: foo_discogs (Read 1347189 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

foo_discogs

Reply #1850
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.

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 ;-)



foo_discogs

Reply #1851
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.

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. :-)

foo_discogs

Reply #1852
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.

foo_discogs

Reply #1853
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

foo_discogs

Reply #1854
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.

foo_discogs

Reply #1855
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.

foo_discogs

Reply #1856
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?

foo_discogs

Reply #1857
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

foo_discogs

Reply #1858
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).

foo_discogs

Reply #1859
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.

foo_discogs

Reply #1860
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...

foo_discogs

Reply #1861
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)?

foo_discogs

Reply #1862
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.

foo_discogs

Reply #1863
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!! ;-)


foo_discogs

Reply #1864
looks great!

foo_discogs

Reply #1865
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.

foo_discogs

Reply #1866
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

foo_discogs

Reply #1867
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.

foo_discogs

Reply #1868
Check that your system clock is set right, that seems to be the cause of that error message.

foo_discogs

Reply #1869
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.

foo_discogs

Reply #1870
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

foo_discogs

Reply #1871

foo_discogs

Reply #1872
Update: https://www.sendspace.com/file/qej9dt

Changes:
* Configurable strings in the find_release dialog. I would advise against adding additional data fields to these strings, as it would most likely require extra API calls to every release/master release, which would be quite slow.
* Change to which artist art is written. The artist IDs whose art is downloaded are now determined by a formatting string (%<RELEASE_ARTISTS_ID>% by default). It used to be that release artist ids were used unless it was a "compilation", then track artist ids were used. Also, only the first artist was used even if there were multiple. I didn't like how inflexible all of this was, and the definition of a "compilation" isn't clear and is being removed from the internals. Also, the filename string ought to be changed (new default: artist%ARTIST_ID%).
* Options to skip find_release dialog if release id is known and to skip release dialog if track orders are matched.
* Slight concept changes to automatic track ordering - using different methods rather than just durations. I'm still thinking about whether something along these lines is feasible or not, and how I'd make it more easily configurable.
* Fixed a handful of bugs.

"Update Tags" feature needs a lot of work yet. I haven't tested it at all, FYI. I'm planning for it to sort all files by release id and then use a similar process to writing tags when updating them (including track matching). To see which ones are written in the update, you'll have to continue using the tag_mappings dialog for now, as I can't see the above being added in the near term?

foo_discogs

Reply #1873
Update: https://www.sendspace.com/file/0xeair
Help doc: https://www.sendspace.com/file/911rd5

Changes:
* Formatting strings for saving artwork vastly improved. Both of the file prefix strings now have a custom field, %IMAGE_NUMBER%, which is the count of the image being saved. This replaces the old method of appending "_2", etc, to the image names. The formatting string also has access (in addition to the relevant ARTIST_ or RELEASE_ object) to the IMAGE_ object of the current image being saved. The IMAGE_ object exposes fields TYPE, URL, and THUMBNAIL_URL.
New default "file prefix" settings:
Code: [Select]
cover$ifequal(%IMAGE_NUMBER%,1,,_%IMAGE_NUMBER%)

artist%ARTIST_ID%$ifequal(%IMAGE_NUMBER%,1,,_%IMAGE_NUMBER%)

* The "release" dialog strings for the Discogs Tracks and Files are now based on formatting strings and are exposed via the settings. The Discogs track formatting string draws from the release, disc, track, artists, etc. It also has custom fields %REPLACE_ANVS% and %DISPLAY_ANVS%. The File track formatting string draws from the file info only.
Default settings:
Code: [Select]
$ifgreater(%RELEASE_TOTAL_DISCS%,1,%DISC_NUMBER%-,)$num(%TRACK_DISC_TRACK_NUMBER%,2) - $multi_if($multi_and(%ARTISTS_NAME_VARIATION%,$multi_not(%REPLACE_ANVS%)),%ARTISTS_NAME_VARIATION%$multi_if(%DISPLAY_ANVS%,*,),%ARTISTS_NAME%) - %TRACK_TITLE%$ifequal(%TRACK_TOTAL_HIDDEN_TRACKS%,0,,'   [+'%TRACK_TOTAL_HIDDEN_TRACKS%' HIDDEN]')

$if($strcmp($ext(%path%),tags), $info(@), %path%)

* Parsing of index/sub-tracks now sets the index track's duration as the track's duration. The sub-track's duration is now exposed separately via %TRACK_SUBTRACK_DURATION_RAW% and %TRACK_SUBTRACK_DURATION_SECONDS% fields (ie. from the track and its subsequent hidden tracks). (TODO: do the same with other stuff, such as credits)
* Fix for matching tracks by existing track numbers for multi-disc releases if tracks per disc are numbered starting from 1.
* Last config tab open is remembered.

foo_discogs

Reply #1874
Hi zoomorph !

I'm having a little bug with last update and the blocked field DISCOGS_TRACKLIST_INDEX:
Code: [Select]
<DISCOGS_TRACKLIST_INDEX> : «multiple values» 1/?; 2/?; 3/?; 4/?; 5/?; 6/?; 7/?; 8/?; 9/?; 10/?

and the update tag feature does not work.

Also I find some problematic releases, mostly related with hidden tracks:
Code: [Select]
<DISCOGS_RELEASE_ID> : 6939
<DISCOGS_RELEASE_ID> : 17435

How can I get all tracks from this kind of releases?