Big library. Whats better: embedded artwork in each track or separate jpg in album folder
Beantwortet
-
Offizieller Kommentar
Hi Hans
Removing all embedded artwork and using a single cover.jpg file in each directory on jumbo size libraries will significantly reduce resource storage and increase App efficiency and response times when browsing your library.
See here for more details; https://support.bluos.net/hc/en-us/articles/360000368827
-
Hi Hans,
There is a great App called Bliss that can run through all your albums removing the imbedded artwork automatically, it’s a great time saver. You can also adjust the artwork size automatically (both size and physics space) and again this helps with resources.
1 -
Thank you Tony, that’s very good information to have. I could not find it in the support pages (including the link you just shared).
Best regards, Hans0 -
And thank you for the advice Seppi I will give it a try.
0 -
@Tony: it would be useful if such information is included in the article you referred to
@Hans: alternative to Bliss would be mp3tag (free for Windows, 7-day trial for Mac); it supports bulk cover art removal and bulk cover adjustment (by specifying max pixel size); unlike the name suggests, most formats are supported
0 -
Big thanks to all of you. It took me not much more than an hour and now the total metadata of my big library is halved in size (with mp3tag). It makes the Bluos app run smoother (it was good but now it’s great). And I don’t need to worry anymore about running into the max library size in the future.
1 -
Out of interest: what did you do, remove the embedded art or resize these? If resizing, to which max size?
0 -
Hi Gerben, I removed the embedded artwork from the biggest albums and replaced with a cover.jpg in the album folder. Before this I already aimed for artwork size between 400 and 600kb. If possible not much lower to keep a good enough quality on a 12.9 inch iPad screen. Not higher than 600kb to limit total metadata size of the library and to be able to keep the optimize artwork setting turned off which results in faster indexing.
1 -
While Tony may be correct regarding the efficiency of the App efficiency and storage I do NOT agree with the idea that all embedded art should be removed from your album metadata. I have recently spent a month trying to resolve a number of art related issues.
For context:
- My library consists of:
- 6,979 albums;
- 95,224 song tracks
- 2TB of data
- approximately 1/3rd (2000 albums) were from physical CD's that did NOT include any album art
- the balance have been downloaded/acquired from several different vendors, the majority are hi-res files
- These have often had multiple versions/resolutions of album art
- Apparently this caused issues with art not displaying in some cases
- I resolved the issues by creating a new folder, within each album folder to store ALL artwork, pdf's, liner notes, etc.
This way there are NO conflicts and the art displayed is the art in the metadata.
- This is important to me because I use my music library as the base for all my music. I DO, make mp3 libraries, albums or more typically just select tracks to use on my i-Phone AND in my vehicles.
- These individual tracks NEED the art embedded in the metadata to display properly on these other devices.
It doe take +-9hours to do a complete delete and re-index of the library, that is done overnight ... and it will ultimately, as my library continues to grow become an issue ... but, I do NOT want to abandon the embedded art and I sincerely do NOT understand WHY BlueSound has chosen their algorithm strategy. I carefully maintain the metadata, ensuring that the art is within the 600kb limit, and that should be the driver IF it exists. It is also true that, in my experience, artwork IS embedded in the metadaata of 98% of the albums I purchase, physically or in download format, hi-res or otherwise. Bluesound has chosen to ignore the metadata IF a file named cover or folder exists within the album root.
Hence I simply disagree with the strategy of removing the embedded artwork ...
0 - My library consists of:
-
Sorry, my library is 4.2TB in total ...
0 -
Hi Ian,
Embedded does not have not be removed, just include cover.jpg (or folder.jpg) in each album directory.
BluOS uses following sequence / preference for cover art (discovered by running some trials a few years ago):
1 cover.jpg
2 folder.jpg
3 embedded (not used if one of the above is present)All my music files have embedded covers, because I wish to have the option to transcode to m4a or opus and not bother about having to add covers again.
Each album directory that contains actual music files has a file named cover.jpg, simply because it is BluOS's first priority cover selection. So an album comprising two CDs has a cover.jpg in both CD1 and CD2 directories. Full index rebuild of 42k tracks takes about 5 quarters hour over wifi, slightly faster over ethernet. A reindex is a matter of minutes. I always perform a reindex, rarely rebuild, only when I start seeing odd things in the BluOS library, typically after moving or renaming an existing album directory.
Unlike you, I keep all scans, booklets (pdf) et cetera in the root album directory, not in a separate one. This would only create another directory that has to be recursed. I do not expect this to make a lot of difference though.
0 -
Gerben, those are fair comments ... but, based on teh difficulties I had with art I beleive that there should only be 1 file in the root directory that is called either cover or folder and it needs to be smaller than some limit, i believe 4MB but I am not sure. I do have many albums with hi-res artwork, larger than 2MB for sure, that I want to keep ... hence I have stored everything in the separate 00 - Scans subfolder ... since BlueSound does NOT, as far as I know look below the album root directory it makes sure that there is no potential conflict ... I also keep pdf liner notes, and articles etc within the scans folder ... that simply keeps my library easier to organize/read, in some cases I have at least a dozen other files for many albums ...
The real point is that you, like me, do NOT remove the embedded artwork, for numerous reasons.
As far as rebuild & re-index time, I am surprised that you can re-index 42000 songs/tracks in 1.25hours mine literally takes almost 9 hours, over wi-fi because there are some problems re-indexing when the 2 nodes and 1 player are connected via wi-fi, hence I am stuck using wi-fi ... I do find that very interesting I have had to delete and re-ndex my library at least a dozen times over the past 4 weeks due to a number of artwork issues. Anyway, I appreciate the thought and comments ...
Thank you
0 -
A reindex (not rebuild) without any changes takes 101 s:
Jan 4 22:39:37 (none) user.info ./ms.pl: main::__ANON__ ./ms.pl (1611) Indexing 41500 files took 99.7 seconds Jan 4 22:39:38 (none) user.info ./ms.pl: main::__ANON__ ./ms.pl (1611) Indexing 42000 files took 101.0 seconds Jan 4 22:39:38 (none) user.info ./ms.pl: main::__ANON__ ./ms.pl (1611) Indexing 42052 files took 101.2 seconds Jan 4 22:39:38 (none) user.info ./ms.pl: main::__ANON__ ./ms.pl (1611) Scanning 42052 files loaded 0 new files took 101.2 seconds
It may be worthwhile looking at your log after such a (no changes) reindex, whether you see anything delaying the process. Note that the logsize appears to be limited to 256kB. You can view the log in a web browser with URL: <bluos device IP>/diag?print=1
If no oddities, repeat the same with a rebuild and looking at the log.
Note I have optimise artwork disabled, none of my covers exceed 1200x1200 pixels or 600kB, see this article on cover size limits:
0 -
Thank you for your comments: I am unaware of any kind of diagnostic log as you have noted. tried typing the following: URL: <bluos device 192.168.1.96>/diag?print=1 into the browser line ... but was unable to see anything ...did I do this correctly ... and I been askiing for any kind of diagnostic log from BlueSound for the better part of 4 years and have never seen one, been shown one...so any kind of diagnostic log would be very helpful. Thank you
0 -
Enter as follows:
192.168.1.96/diag?print=1
0 -
Thank you, that worked and I was able to see/print(pdf) of the log. 27 pages ... but, alas, I do not know what it tells me ... but thank you ... I did try a simple re-index, twice this AM, first with optimize on and then with it off ... in my case both simple re-index's took between 15 to 20 minutes ... for my 95,000 track library, over wi-fi ... tonight I will re-run a complete delete and re-index again, this time with optimize art off ... that was taking on the order of 5-6 hours before I relocated all of the art files to the separate sub folder 00 - Scans just to see how long it takes ...
Again, thank you for your thoughts and insights, I appreciate them and your assistance ...
0 -
In the web browser you can search the page for "index" to get to the listing of indexing progress.
Reviewing your picture I see one of the things you should amend: the cover.jpg or folder.jpg should be in the Dark Side of the Moon folder, where the flac files are.
If it is in the Scans folder, it will not be associated with the flacs and the embedded covers will be used.
Make sure that every folder that contains the music files of an album, also contains a cover or folder.jpg or png.
0 -
Thank you ... I specifically moved every .jpg .png etc to the Scans folder I created and each album file does have correctly sized embedded art ... haivng completed all of that all of my art issues have been fixed ... having said that I am beleiving that your advice is indeed the best advice:
- keep the embedded art
- keep one cover.jpg file in each album folder because BlueSound preferentially uses that file for indexing purposes ... I am still not sure WHY they want to use that file if the art is embedded but so be it ... that is their algorithm
Thank you for your thoughts and insights ... you have been very helpful.
0 -
BluOS has no idea how you have organised your library, you may have plonked all 95k audio files into the same directory.....
By following the principle that if a directory contains a cover.jpg (or folder.jpg or .png) the embedded covers are ignored, they can speed up the indexing by not having to read the embedded cover of each file.
Realise that to index your or my library, every directory shall have to be scanned and each directory for every file it contains. Otherwise BluOS will not know which directory contains music files and which does not.
0 -
I am not sure I understand that. I have organized my library very carefully:
Artists stored alphabetically.
Every artist & album stored in separate folders. I am pretty sure that most people follow a similar strategy ... only way to organize 6,974 albums and keep anything straight/organized ...
Each album within a folder by artist
I would actually like to know how Bluesound goes through my Library during an index/re-index and delete & re-index ... I sincerely would like to understand their algorithm ... I am unable to follow it looking at the log I printed ...
Interesting ...
0 -
And it has been organized like this for over 20 years ... when I started using Windows Media Player and then SONOS and now BlueSound ... just a matter of interest ... :)
0 -
So that is pretty different from how I have organised it into directories: first level is container type (flac, opus, mp3 etc), second level is genre, then composer or album artist and so on. But BluOS or Media Player have zero knowledge of how you or I physically organise our libraries on disk and what such may mean.
Eventually, it really does not matter how we have physically organised our library, a media server has no other option than to scan every directory in the library for the presence of actual music files and then build a catalogue from the metadata.
BluOS has just added the option to (optionally) include a cover file (name and type following their rules) in any directory that contains music files, in order to skip scanning the embedded covers.
How BluOS, subsequently, builds its music server index from the metadata would be truly interesting to know in more detail.
0 -
Understood and of course different people will organize their libraries differently, always interesting to see how people do this. And you are correct, the BlueSound/server must analyze the metadata for numerous reasons ... and that ultimately is WHY I carefully manage the metadata and store all the artwork, embedded in the metadata ... AND ... I do not see the reason to ignore the artwork stored within the metadata and use a separate artfile IF the artwork exists within the metadata.
And that has been my core issue working to resolve the display of artwork by BlueSound.
I make sure that my embedded artwork comply's with the size limits, yet BlueSound will ignore the metadata and use an art-file if it exists ... as it turns out, apparently, if there are multiple resolutions of art-files, or multiple types of art-files in the album directory, both jpg's and png's there can/will be display issues. I had several hundred of my albums with this issue, so even though my embedded artwork was correct it would not display due to a conflict with the other art files.
Anyway, after all of the back and forth with support, and inconsistent results, I decided to go through my entire library and relocate ALL artwork to the 00 - Scans folder I described. That resolved all display issues.
Having said that I do believe that your suggestion, to keep one art file called cover.jpg, that is the correct size within the album directory is the optimal strategy to manage art, with both small, large and very large libraries. Which was the original issue raised by the other user.
Ultimately I will edit my library accordingly ... but I also have experimented with optimize artwork On and OFF ... the re-index is definitely faster with optimize OFF and I have not seen any significant difference with response, delays in display of artwork etc. with optimize off ...
Just my thoughts ...
And again thank you for your very rational thoughts, comments and support.
0
Bitte melden Sie sich an, um einen Kommentar zu hinterlassen.
Kommentare
23 Kommentare