This is just weird.
IF an album title contains numbers, I keep getting a 400 code error. However, if I remove the numbers (or remove the full title), I can then find the album in MusicBrainz. I have done this with multiple recordings today and I have the same issue.
Build: v3.32c (64 bit)
Video: https://youtu.be/qsqZ16JkibE
This syntax should work for your Album of Magic Sam:
Yes.
When presenting the search dialog where you enter the search strings, Mp3tag automatically removes characters that are special characters in the query language of the indexing server that is used by MusicBrainz (cf. Escaping special characters in Lucene).
It means that using \(1937-1969\) also works as an album name, in addition to the workaround from the previous post.
However, what I don't understand so far is why using plain 1937-1969 doesn't return any result. It also doesn't when using indexed search on MusicBrainz directly.
It seems that the hyphen-minus between the two year numbers will be treated from Lucene as logical operator and means "exclude the following from the result"
If you escape the minus at MB, the encoded query seems to work:
https://musicbrainz.org/search?query=1937\-1969&type=release&limit=25&method=indexed
The API seems to work differently in that regard:
1937\-1969 doesn't produce any results
https://musicbrainz.org/ws/2/release/?fmt=json&limit=50&query=release:1937%5C-1969%20AND%20artist:%28Magic+Sam%29
Using fully escaped parentheses \(1937\-1969\) works
https://musicbrainz.org/ws/2/release/?fmt=json&limit=50&query=release:%5C%281937%5C-1969%5C%29%20AND%20artist:%28Magic+Sam%29
and also without escaping the hypen-minus \(1937-1969\)
https://musicbrainz.org/ws/2/release/?fmt=json&limit=50&query=release:%5C%281937-1969%5C%29%20AND%20artist:%28Magic+Sam%29
The mentioned syntax "(1937-1969)" works too:
https://musicbrainz.org/ws/2/release/?fmt=json&limit=50&query=release:"(1937-1969)" AND artist:"Magic+Sam" or the same API-query partly enquoted.
Unfortunately, the parantheses around 1937-1969 can not be wildcarded with a * or ?
As far as I know, this is because they are part of the release name (aka "Album") and for the following reason given in the MB documentation:
This "fuzzy search" syntax with added ~0.5 would work without parantheses, but is far from obvious:
Again from the MB documentation:
Thanks for the additional information. Unfortunately, I don't see a generic solution to this issue at the moment.
The discussion also shows, that it's not a bug in Mp3tag, but a combination of different syntaxes that need to be applied carefully to get the desired results.
I'm moving this to Development > Web Sources Discussion for now.
