Suggestion: Full cover preview at search results (was write access to "CurrentPreview" from within ParserScriptAlbum)

Development Web Sources Discussion
1

I wanted to implement a configuration setting for websource scripts, that controls the Preview button on the List of search results and the This Album on *some server* labeled URL on the Adjust tag information screens. The previews should show the Cover of the album in wysiwyg-manner in a browser window if the corresponding configuration option is set.

Using the (undocumented) placeholder %_preview% in

[IndexFormat]=%_coverurl%|%_preview%|%_url%|...

and supplying the coresponding URLs in the ParserScriptIndex block of the web source script works well, as long as a search for the album is needed.

But I want to use this feature also in cases where the album URL (or other album identifiers) are already known and only the ParserScriptAlbum block is used. In this case the output buffer "CurrentPreview" always contains the preview URL of the album (set from Mp3tag). If ParserScriptIndex would have been executed, the content of "CurrentPreview" were taken from %_preview% placeholder and could contain the cover URL or the album URL, depending on the configuration setting.

In ParserScriptAlbum actually it is impossible to write to the output buffer "CurrentPreview". Any attempt to change its content has no effect. So the configuration setting for cover preview only works for searches and not for already known albums. This is especially bad for web sources like [WS] Bandcamp (search by URL), that don't support searching and therefore this feature can not be implemented in such a script.

Therefore I suggest to enable a writeable output buffer "CurrentPreview" in ParserScriptIndex. There are other use cases, that request for a way to transfer arbitrary data from ParserScriptIndex into PaserScriptAlbum, and therefore could benefit from that feature, because the transferred data could be removed, e.g. [WS] Cover Art Archive by @rboss .

2

Hello @yorickausyps,

If I'm understanding your context correctly, your goal is to have the album preview link in 'Adjust tag information' window to return the image URL for the resulting album instead of the source page of that same result. And this would happen for known albums (from your description, these would be albums that only return one hit when searched, therefore skipping the 'List of search results' window).

I'm writing this before testing, but I believe this is already accomplishable with the current toolset, and insight on how MP3Tag processes searches.

EDIT: I wrote the following before checking your current Bandcamp script, and was assuming
`ParserScriptIndex` was present. But for the suggestion I'm presenting the next bit is
 still relevant.

This is not entirely correct; even in one-hit searches ParserScriptIndex still runs (edit: if present). If in your WSS of choice you enable both ParserScriptIndex and ParserScriptAlbum debug modes, when running a one hit search that directly goes to 'Adjust tag information' both debug outputs are generated.
ParserScriptIndex does run, but in these cases (one hit results) having to go through 'List of search results' to select the only option avaliable is redundant, and so MP3Tag makes this selection internally.

Knowing this, the next step is to access the URL link data in order to modify it.
The link itself borrows from 2 sources: one for the text that is displayed, and one for the URL.

The first one is easy, if viewed in this format: "This album on %name%"
Where %name% corresponds to the [Name] variable, set on your WSS. This is a single value, that cannot (currently :wink:) be accessed during runtime. But this is just for the text data, so it's of lesser importance.

The URL source is -as you mentioned- the %_preview% variable, which is dinamically generated in ParserScriptIndex from served data.

With the previous knowledge that this script block still runs, even on single-hit results, in order to achieve your goal you'll have to modify the value of %_preview% from a webpage URL to your image URL of choice.

In fact, since the introduction of cover preview thumbnails this is already being done: If your source can provide data for the cover preview thumbnail, then it would be a matter of duplicating the value of %_coverurl% into %_preview%, and the corresponding link in ' Adjust tag information' would now connect to the same image, but opened in a browser.

I took a peek at your Bandcamp WSS, and better understood your current position. There is no ParserScriptIndex block in your script, and therefore no way to achieve what I suggested above.
Then if you can add it, you can fashion a single search result, one that includes the %_preview% variable, pointing to the cover image URL, present in the source data. Which will then be used in the clickable link in 'Adjust tag information'.
Because it's a single result, 'List of search results' will be skipped, and from a end user point-of-view, operation will be indistinguishable from your current version.

Hope this helps.

3

Hello @rboss,
Thank you very much for your detailed contribution. I'm sorry, that I didn't tell the whole story in the first place.

The above problem description relates to the [WS] Deezer, that I had reworked and completed with configuration settings and other extensions two month ago.

Meanwhile I detected, that the cover preview feature in this last release of the Deezer WSS only works with (real) searches for artist + album and artist + track. The other scripts, that use an album/artist/track-ID or an URL, never show the cover when clicking on the preview URL. This is because these scripts don't need to search for something and consequently don't have a ParserScriptIndex block.

My suggestion to allow writing acess to the output buffer "CurrentPreview" in ParserScriptAlbum would be the easiest way to clear the issue, that the preview URL can't be changed or set. The workaround you suggest via using a "fake" search for an album with a one hit result surely would work, but this involves much more programming work and computer resources. Also the user surely would notice this two step process, because the latest Mp3tag now displays progress bars for both phases, the retrieving search results and the retrieving metadata.

I mentioned the Bandcamp WSS, because the bandcamp server requires javascript for performing searches and Mp3tag doesn't support javascript. Consequently for Bandcamp the one hit result search workaround is not possible.

4

Because I do love a challenge :grin:, when someone tells something can't be done, the more eager I become to try it.

Has I had mentioned, there is no need to perform an actual search; using a "mock search" via scripting can trick Mp3Tag that a search had been done and get the job done.

I spent some time on this and came up with something that appends to your original work, and I believe performs the task you were asking. Please give it a try:

&Bandcamp#Bandcamp &AlbumB.src (771 Bytes)

If this is what you're looking after, I could try a similar approach in Deezer.

I also have to admit my mistake-

There are, in fact, 2 progress bars -one for each ParserScript block- visible during a search. I mentioned the end user wouldn't notice, but it is noticeable. :upside_down_face:

5

Thats great, and so simple! As always, the simplest ideas are the best!
Thank you very much for sharing your code!
Actually I have this concept working for Deezer already.

6

No problem.
But out of curiosity, what is your use case for having the source link point to the cover image URL, instead of adding the simpler COVERURL tag in your results?

It obviously saves a copy-paste operation to open the image URL in a browser; but on the other hand, the album info page now becomes unavailable - unless you script a SOURCEURL to your results.....
:thinking:

7

My intention was to implement a full size preview of the cover on the "List of search results" screen, that is reachable with one click only, becaause the mouse hovering over the cover thumbnail does not show much details. This seems to be missing at this screen, especially if you are primarily looking for covers and not for other metadata.

I will no longer follow this project, as it turns out that overloading of the preview button has undesirable side effects for the next screen "Adjust tag information", that can't be repaired, because the output buffer "CurrentPreview" can't be set in ParserScriptAlbum. This screen already offers a full size preview, simply by clicking with left mouse butten onto the image, and does not need a second preview option by clicking on "This album on ". Also the link to the source for album metadata can't be called any more here, because the overloading of the preview button on the previous screen can't be reverted.

After all the suggested feature for write access to "CurrentPreview" from within ParserScriptAlbum still seems to be a useful option, because it would allow to fix the above problems, and it would enable a better transfer option for data from ParserScriptIndex to ParserScriptAlbum without side effects, because the data could be removed after the transfer and the preview link would be left intact.

8

By "much details" are you referring to visual details (as in 'does this cover look good' or image file details -filesize, dimensions, quality, format, etc.)?

Because, by its very nature, the search results page is intented (I presume) to list a large quantity of small-sized (in bytes) entries (normally album header info).

If I were to have the preview thumbnail to show high-quality covers -let's use a 1Mb image per cover for example- and get 100 search hits, Mp3Tag would have to process (at least) 100 Mb of data, which -depending on the user's system- would have an impact on performance.

then would it not not make sense to have the search results window return cover metadata (image format, size, dimensions, compression, etc.) to facilitate the primary cover selection process while keeping network bandwith and system resources at a manageable level, and only loading the 'full picture' in Album Info?

EDIT: Here's an idea I just had, that is not possible at the moment, but may become a feature suggestion:
what if the search results window had a column with hyperlinks, or some form of clickable link that could be filled -for your usecase- with cover image URLs?

Then there would be a way to access on a browser window the full cover image (which the modded script I shared enabled, but only one per selected album), and could have multiple links listed via the search results for ease of access, all without sacrificing system performance, or having a long wait time for results.

Would such a feature serve your purposes?

EDIT2: I realized the 'Preview' button already does this for the %_preview% column in [IndexFormat]; so that to open cover URLs externally from [Search Results] is simply a matter of having the intended cover URL output to the proper position in %Output%. Which I think you have already tried, when you mentioned

For my previous idea to be feasible (while maintaining the previous functions), there would have to be some form of %_preview2% column, and a 'Preview2' button (or the same button click + a keyboard modifier) which may not be possible and/or user-friendly.

9

Yes, e.g. contrast, false color tone, reflections of cellophan hulls, scan or photo etc.

A cover preview, that is user friendly in my opinion, could be just to click left on a cover thumbnail while hovering the mouse over it. Then, with a left mouse button click, the full cover could be downloaded and opened in the browser (or an image viewer). This could e.g. be implemented, from WS script point of view, by mp3tag accepting two urls in %_coverurl%, the thumbnail url like until now and, separated by e.g. a space, the url to the full cover for the preview function.
This would be an extension of mp3tags current interface, that has no impact on performance (no data is loaded) and doesn't disturb other functions of the list of search result screen. The image view in browser or image app would also offer technical data about the loaded image (size, resolution etc.). Perhaps it is not much work for @Florian and he likes this idea?

10

I had the same thought, and from a UI standpoint makes sense to open a cover url via double-clicking the respective thumbnail. But I don't know how flexible the scripting framework is/needs to be to accept 2 data points (cover thumbnail url+full image url) for the same column.
Additionally -as I had laid in my scratched idea- the more versatile option would be an 'external link ' column, which could be used for your use case of external cover url BUT could also serve for other linked data (like I suggested for the external album page -or something else).

I've also been trying to emulate a workflow based on our exchange: with your suggestion in effect, and double-clicking the thumbnail to open the respective full image in a browser instead of using the preview button to the same end, the only tangible benefit I'm noticing is in the speed with which you can open cover URLs in bulk.
With keyboard help, I could: double-click thumbnail > browser window opens > use Alt+Tab (Windows) to go back to Mp3Tag > double-click next thumbnail > [repeat].

With added cover URLs to %_preview% (already feasible) and using the Preview button, the workflow would be: Select album entry > move cursor and click 'Preview' > browser window opens > use Alt+Tab to go back to Mp3Tag > Select next album entry > [repeat].

And if you're willing to, just using the keyboard alone can get results even faster: with %_preview% pointing to cover URLs; select the first entry in Search Results, then the workflow loop becomes: Shift+Tab to select 'Preview' > Enter or Space to open cover url in browser > Alt+Tab to go back to Mp3Tag > Tab to go back to album list > Down to select next entry > Shift+Tab to select 'Preview' > [repeat].

There are more steps, but with practice it can be done faster than with the mouse/cursor, because there is no cursor motion. It can even be done with automation tools or keystroke emulation.

11

If thumbnail and full image have a consistent pattern, maybe you can build the URL with some regex!?

Just a thought, but I'm nowhere near a desktop computer to try something myself.

12

It's not the data content where I'm imagining trouble; if @yorickausyps's suggestion of the preview pop-up also doubling as an external link were to be implemented, there would need to be 2 (different) values for the same column. Or to put it in a more graphical form:

[IndexFormat]= %_coverurl% | %Column header1% | %Column header2% | %Column header3% | .....
[Output]=      thumbURL    | value2           | value3           | value4           | .....

is what we have now; what would be needed would be

[IndexFormat]= %_coverurl%     | %Column header1% | %Column header2% | %Column header3% | .....
[Output]=      thumbURL+imgURL | value2           | value3           | value4           | .....

...besides making the pop-up clickable. In this (very simplified) example, the problem becomes "How to declare both thumbURL and imgURL to be read in the single %_coverurl% column by Mp3Tag?"

This is the point I think is beyond the current capabilities of the WSS framework.
Or so is my opinion.

13

'Preview' has a keybourd shortcut of it's own: Alt+P, so the workflow becomes even shorter: Alt-P opens cover in browser, Alt-Tab gos back to mp3tag, Down Arrow selects next extry, repeat da capo. These are only 3 steps. (I really like keyboard shortcuts.)

Currently only one url is accepted in the '%_preview%' column. If an additional column e.g. '%_fullCoverUrl%' and a corresponding button 'Full Cover' with shortcut Alt-F would be implemented, this would surely fulfill the function and require also only 3 steps with keyboard shortcuts.

14

... and I learned something new today. :+1:

Going back on topic, taking a step back and digesting the thread form the beginning:

I think we can both agree that your idea of double click a preview thumbnail to open a full image link via browser is not feasible with the current build of Mp3Tag. If someone can make it happen, that would be @Florian so the suggestion stands.

A middle ground has also been discussed: keyboard shortcuts + having %_preview% pointing to a cover URL instead of an album page URL already accomplishes most of your original intention, and is perfectly feasible with the current build.

With this quote I'm presuming you would prefer having the current preview column + Preview button as is, and add a second column + second Preview button dedicated to (in this case) cover URLs.
From my perspective, I'm reading that you want all the current preview features, plus an additional button that would behave much like the current one, only for a different source link (cover image instead of a webpage).

:thinking:
...10%
...25%
...50%
...75%
...100% complete.
:light_bulb:

You have control over what %_preview% will show; as mentioned and test-scripted, this can be done in ParserScriptIndex via "mock search".

With a bit of scripting, you can also bind this data to an IfVar command.
Let's say for example, "IfVar [Setting=true] then Say [cover URL] Else Say [album webpage].

Using this, I think (untested- I'm having this idea while typing) you would end up with a Search Results page that -while not able to open with double-click- will either open an album webpage OR the cover image URL via keyboard shorcut, with the toggle between either result managed from Settings.

You can keep the Preview button that already exists, and dynamically assign what that button will open from a setting. With a keyboard shortcut to perform the required action; something I'm reading you're already fine with.

I believe this is the closest to your vision that can be done via scripting, and possible with the current tools.
Anything more will require a new Mp3Tag version, and that would be up to the developer.

15

I've read the whole topic, but there are quite a few different ideas floating around and I'm not sure entirely, if I understand the motivation behind the suggestion.

@yorickausyps, could clarify which of the options you're suggesting?

  1. A way to display the full cover image for Tag Sources that jump directly to the result dialog (skipping the query results dialog).

  2. A way to modify CurrentPreview from ParserScriptAlbum so that you can use %_preview in creative waysTM and restore its actual purpose in ParserScriptAlbum.

  3. A new technical placeholder similar to %_coverurl% for ParserScriptIndex that is filled with the URL of the actual cover image that's used when importing the release. This also would allow for a Cover button to be added next to the Preview button.

  4. Or something different, I missed from the discussion above.

16

It is point 2 that I want to suggest:

My original project has changed, but my conclusion is still the same.

With a configuration setting "previewCover", I would like to optionally change the preview function only on the "List of search results" window and not on "Adjust tag information" any more, because for the "Adjust tag information"

  • the full cover has already been downloaded and with a click on the left mouse button it can previewed in the users image app,
  • would be no way to call the souce page for the album with the "This album on [Name]", effectively removing a needed function from this window.

A code example in ParserScriptIndex for the Discogs WS is

# Optionally overload Preview button with full cover url
IfVar "previewCover" "true"
	json_select "cover_image"
	say "http://cache.mp3tag.de/coxy"
	sayregexp "(?<=\.com).*"
else
	json_select "id"
	say "https://www.discogs.com/release/"
	sayrest
endif

and in ParserScriptAlbum

# Reset This album on Discogs to album url
IfVar "previewCover" "true"
	OutputTo "CurrentPreview"
	Set "CurrentPreview"
	json_select "uri"
	sayrest
Endif

The problem, why this actually is not feasible, is that the output buffer "CurrentPreview" can not be reset in ParserScriptIndex (Edit: must read ParserScriptAlbum here). The link behind "This album on Discogs" still points to the cover preview and not the album release. This would really be my favorite solution, and it seems to be the simplest change in mp3tags source code compared to the other suggestions.

Introducing a second button is no good idea, because none of the tenths or hundreds other WS scripts will ever support it. Also clicking on the thumbnails for a preview while hovering is not an alternative, because the left mouse button is already used for selecting the row and going to the next screen. An option could be to use the shift or control key together with clicking the preview button or keyboard shortcut Alt-P.

17

A variation of this:

Could the 'Preview' button be modified into a dropdown menu, and have %_preview%, a possible %_fullcoverurl% and other future variables be accessed from there?

18

Thanks for clarifying! So you're aiming at option 3. from a functional perspective, and would suggest option 2. from a technical perspective.

I think you meant to write ParserScriptAlbum here.

It would be possible to only show the button for Tag Sources that support the full cover URL.

It's possible, but would involve new steps in first triggering the menu and then choose an item.

19

I've added those two with Mp3tag 3.36-beta.6. The new placeholder is named %_coverfullurl% and I already updated the builtin Tag Sources accordingly.

20

Thank you very much for these new features! The cover preview button is working smoothly. It actually makes my use case for setting CurrentPreviewinParserScriptAlbumpointless, but maybe someone else has an application for this.