Searchable via https://musicbrainz.org/search?query=-script%3A*&type=release&limit=25&method=advanced
We will be switching to a consistent syntax as above to find all unset fields.
2 Likes
While I felt the old search was a bit odd to use, giving me dozens (sometimes hundreds) of unrelated results, including results that I can’t even figure out how or why they could be included…
The new search could maybe be expanded a little. For example:
I searched confederate railroad, but I misspelled it. My search, confederate railrold, gave me zero results.
While zero results is technically correct, a loosening of the criteria could be useful. Especially when considering simple name variations (john vs jon or smith vs smithe).
5 Likes
I’ve noticed 2 bugs with the new search system.
-
When searching by specific release date, search results include releases where only year is specified in release date field. Previously such releases were not included (and I believe they shouldn’t be). Example of query: https://musicbrainz.org/search?limit=100&method=advanced&page=1&query=date%3A2018-06-30+AND+status%3Aofficial&type=release
-
Something is wrong is paging. If you run the query above and try to switch from page 1 to page 2 and back several times, you will see that content of each page is not permanent. Or you can simply refresh the page several times - in 50% cases it will display different records.
1 Like
Have you got some tests for this new search. If not you really need some otherwise you’ll find that as you try and improve things for one type of search you will inadvertently make the results worse for another search.
If I search for Chris de Burgh I get 60+ hits. If I search for Chris deBurgh I get one hit (the correct one).
1 Like
I am not sure what’s wrong with giving correct results? The de burgh search finds more results simply because of the fact that those results match the terms. The correct result is still number 1 either way.
1 Like
The de Burgh search appears to return any name which includes a portion of my search string - unless I enclose it in double inverted commas. That’s probably what it is programmed to do. I have no problem with that.
What I found strange was that it gave me just the correct name when I searched for what was in effect an incorrect name.
My local tax bill hasn’t been paid for years. They keep sending the tax bill to the wrong person. A simple misspelling of my name voids my obligation to pay them. Correct address. Phonetically acceptable version of my name. But it is spelled wrong.
Correct results are awesome.
But a simple spelling discrepancy between de burgh and deburgh shouldn’t be excluding other spelling discrepancies.
Think about it; if I search the spelling included on a news article, and I get no results. My first instinct is not to try other spellings since I am reading a news article that has that spelling. I am going to add a new artist entry.
But, if I got a list of results that are not exact, but are at least close, my first instinct is to open them to see if there could be a misspelling - especially if some of the other information is filled in (disambiguation, dates, places, etc).
3 Likes
In my ideal world, at Big Rock Candy Mountain, I can set a sliding level switch anywhere from “exact search term” to “very very fuzzy search term” and have the results morph in front of my eyes.
1 Like
In relation to MB Release
In a search of Releases for Jérusalem:
ONE
The new search and the old search both return Releases by Artists named Jerusalem higher in results than Release titles that contain Jérusalem.
See:
https://musicbrainz.org/search?method=indexed&page=6&query=Jérusalem&type=release
&
https://musicbrainz.org/search?method=indexed&page=7&query=Jérusalem&type=release
Do others expect, in a search of Releases, to have all Release titles that contain Jérusalem to appear before Releases that do not contain Jérusalem in the Release title?
Current and old search both appear to be over-weighting appearance of this search term, or a variant of it, in an irrelevant field.
TWO
Current search is returning Releases with Jerusalem in title before Releases with Jérusalem in title.
See
https://musicbrainz.org/search?query=Jérusalem&type=release&limit=25&method=indexed
Search appears to be placing results that match on number of words in Release title higher than results that match spelling (diacritical marks) of Release title.
Is this desired behaviour?
1 Like
Which is what I eluded to a few posts earlier.
New search is far nicer than the old search which gave hundreds of unrelated results. But there should be a way to loosen how tight the results are.
Instead of 1 exact result with the new search or 100 unrelated results with the old search, maybe 10 results is better - a combination of the 1 exact match and 9 possible matches.
2 Likes
I had some cases where I entered an artist search (from relationship editor) with typos or switched some letters… and get no results at all.
Or for some longer names (with 3 or more parts) I only got a result when nearly the whole name was typed in. Even when it was unique previously.
2 Likes
It would have been easy to limit the number of searches to a more manageable number, it would be rather more difficult to change the way the search worked depending on the slider value. But if you are not getting enough results now there needs to be a significant change to how the new search works so that it can do fuzzier searches.
I’m looking at Picard>Options>Metadata>Preferred Releases - Preferred release types
which has 15 sliders allowing search results to be adjusted to the user’s understanding.
There are times when a very strict search is what is sought.
Exact spelling, exact word number match, exact field.
And other times when a match with a differently spelt alias, with a different number of words, in a non-specified and only loosely related field, would be best.
2 Likes
I am not using picard. I am on the website.
Also, I am not talking about a specific number of results, I just used those numbers as examples.
Separate from the “results could be expanded” issue…
I have noticed that sometimes search switches languages on me.
No, I have not noticed a pattern. It just seems to, at random times, say:
Recherche indexée
Recherche indexée avec la syntaxe de requête approfondie
Recherche directe dans la base de données
Searching again brings it back to english.
Pls excuse my lack of specificity.
Picard>Options>Metadata>Preferred Releases - Preferred release types
which has 15 sliders allowing search results to be adjusted to the user’s understanding
is an example of where a search is tailored by the searcher to get returns closer to what they seek.
The search on Musicbrainz could be set up in a way that somewhat parallels the set-up at Picard>Options>Metadata>Preferred Releases - Preferred release types
This would allow one person to get highly specific returns and the next to get very broad returns.
Searching for “riot”, “Riot” or “RIOT” shows partial matches first (e.g “Riot V”, “Quiet Riot” or “Tha Riot”). I would expect it to display stuff like RIOT, Riot or Riot at the top.
2 Likes
I was happy that my new artist were not “available” without doing a direct search, but I may have added duplicate artist because I cannot effectively search as I use to.
A artist with the first name “Richard” could be in the DB as “Rich”, “Rick”, “Ricky”, Richy", “Richard”, other. IMO a search of “R xxxxx” should return all artist with first name starting with “R”. “Robert” is a more interesting first name as it could be “Bob”, Bobby", “Rob”, “Robby”, other.
2 Likes