I made one change to the scripts that were different in them to begin with.
The js version accesses .Metadata default property only once, but the other did it twice (first for "audio" then for "image").
Now it stores that value the first time, so both access it once.
Not sure if the old one would reduce performance or not, but I could as well just fetch it once.
No it only applies to the cover art (because in normal use, Opus doesn't use the cover art images except in the metadata panel, so it would be wasteful to store them in memory all the time).
Talk about metadata panel. Did you see that I mentioned it couldn't delete non-png/jpg coverarts?
I guess it isn't really a big issue, but I scratched my head a bit when I saw DO happily display the gif/bmp
coverart, but couldn't delete it using the panel nor access its width/height properties through a script.
Edit: If the files uses id3v2.3 tags DO will show the gif/bmp coverart it in the tooltip, even though DO doesn't support that
format for coverarts.
The itm.Metadata.image version for getting image dimenions is down to about 20 seconds now, the js version still is twice as fast.
I quickly edited the js-version to return itm.Metadata.image.picwidth/picheight instead of kicking loose with myarmors custom js-parsing.
It then takes 10 seconds more and comes in at about 20 seconds as well. So Metadata.image is slower!
Jon, is this a challenge or what? o))
I tried testing it inside a folder with only png's on a USB2 drive. An USB2 drive is slow enough that it is possible to scroll the screen while its retrieving the dimensions.
The folder has 300 files, and on my computer the js version was lagging behind about 10 files compared to the image meta version when it
was reaching the end. I'd say its about 1-2 second or so difference at the end.
I sorted by the JS column.
The testimages were the glyfx aero13 pack/vista word processing 32x32 png images ranging from 300B-5100B each.
My relevant specs: i7 3770K not OC, hyperthread enabled, idlestates enabled(!), 16GB 1600Mhz ram.
The USB drive is a Kingston G3 32GB.
I'd think having both columns enabled at the same time, will influence execution speed? I mean we don't need to make this more scientific than needed, but.. O)
Now I tested like you, with 1700 jpg files in the same folder, 2.7gb total size.
Builtin Picture.Dimension column: 16s
Script colulm using Metadata.image: 17s
Script column using your js-parsing: 88s
These are measures I expect, so Metadata.image is not slower in general, sorry Jon! o))
But if I test this as before, with dimension to fetch from 800 images, each within a folder, the js-version still is nearly twice as quick (12 to 20 seconds in last test), weird! o)
That doesn't sound too unlikely with files averaging 1,6MB.
The js column seems to be on the slow side, but there doesn't seem to be alot to shave at a glance (with my limited knowledge of JS and image formats).
I would've been happy if it really was true that it performed rather well, but for a js experiment it isn't so bad.
Reading byte by byte isn't really very effective to begin with (all blobstream functions does that), and jpg files seems to be the
most complex ones to retrieve sizes from.. which is probably obvious from the code.
I'm not sure how much it actually reads, but it is probably more than your regular bmp/png, and most likely gif too.
I don't think it should encounter that situation very often, at least not with that many images in the same folder.
I guess the question now might be what causes the slowdown when the metadata version has to scan through the immediate subfolders for specific images.
Jpg might be the most complex to get the sizes out of, but it doesn't read more than 55-71 bytes per file in order to retrieve it (based on selection of ~2000 600KB-2.7MB jpg files).
I couldn't get it to be as slow as your test, but if it is at least somewhat slower than the builtins it wouldn't be surprising.
I noticed that these scripts do the same as the rename scripts, iow the global variables remember what the previous file did..sort of.
I investigated a bit more in the meantime. The slowdown for the js-version is not the js-parsing of the blob itself. It is the prior call to file.Read() that's causing things to slow down immensly.
That js-part to parse the dimensions out of the blob is fast as hell, no serious impact on execution time at all. Speed-testing things is a bit difficult, there's a lot of caching involved it seems, as execution times differ greatly, so I concentrate on the fastest runs only, even if caching was used to full extend, because that's what it's there for. My assumption is, that file.Read() at some point does not benefit from any caching if there are to many items in the file display. For 800 files or folders things can get as fast as with any DO-native dimension column, but for 1700 files or folders e.g., file.ReadAll() suddenly increases execution time by a factor of 6 for no obvious reason.
The other thing we talked about, accessing item.metadata more than once, does have an effect actually. But only if this is done in conjunction with images in a subfolder. Don't know why that is, but my growing excel table for these tests tells no lies, I hope at least. o)
Freaking awesome is DOs memory consumption in the meantime, it's at 3.5GB right now and all I did was column speed comparisons. Is that healthy? o)
Can you explain why you think that?
File.read is sort of expected to take a while as it currently loads the entire file into memory.
It seems that it probably can do with ~100KB for jpeg (but is effectively unknown), 30 bytes for png, 50 or so bytes for bmp, and unknown for gif.
I noticed the thing with globals when I made a global gBytesRead at the top of the script:
var gBytesRead=0;and then in the .ReadByte I did:
gBytesRead++It suddenly started to add all accesses by all files together (I used DOpus.Output to display the value for each file), not just for a single file.
If the script isn't executed again for some seconds then gBytesRead resets to 0 the next time it is executed.
If you refresh repeatedly it displays the same behavior.
Hey myarmor. (just spoke to something I wear.... awkward...)
I was wondering if OGG Vorbis tag support is possible, so that FLAC files could have their coverart as well. FLACs use a format identical to OGG Vorbis. Not only that, but the picture tag block uses picture types according to the ID3v2 APIC standards (see here)
If you do not know, FLAC (Free Lossless Audio Codec) is the most popular format for lossless music, which people prefer to use for high quality rips, mostly from vinyl records which are still being made as we speak. Only last month vinyls hit an 18-year high in sales in the UK (see here). Also, based on results from RIAA in 2009 (which may or may not be biased), Vinyls seem to have been sold at the nearly the same rate as CDs from the year of Compact Disc's origination (1983) to the end period of RIAA's screening (2008).
Details on FLAC's tagging format can be found in the below locations:
xiph.org/flac/faq.html#general__tagging
xiph.org/flac/format.html (more specifically the Picture format section)
@Drakonas, it seems DO metadata don't support coverart in flac files.
Its metadata reports that there are 0 coverarts even when a flac file has coverart.
Also note that you apparently can't add or remove coverart to a flac file through DO's metadata pane.
Can you see the cover art when in thumbnails mode?
Not sure about thumbnails mode (never used it), but the flacfile's tooltip shows the coverart.
Edit: I managed to switch to thumbnail mode, and yes it shows it.
I converted one of my mp3's to flac using Nero 2014, then added the coverart (.jpg) using mp3tag.
Yes, I can: db.3rdn3rd.com/img/2014-12-22_23-49-12.png
Here's an example FLAC file for you to test with:
drive.google.com/file/d/0Bw4ThV ... sp=sharing
(It's a good listen too 
)
Don't worry, the music is legally free, and not licensed.
You can enter 0 on the album purchase here if you want to feel the vibe, or donate like I did. ^^
Sorry, but I had to comment... eww... You just made a non-lossless FLAC... not a concern for our debugging, but I'm an audiophile. It hurts my brain when I hear someone transcode and/or upconvert an MP3... Did you know that when you convert an lossy audio file (MP3, WMA, M4A, OGG) to anything else, lossless or not, it loses some of its audio data?
lol, I know. However, the purpose was to make a file in flac format for the test, so the contents didn't matter.
Then, it seems that the DOpus team better get on top of this. 
I just realized that perhaps dbPowerAmp is doing the CoverArt processing for me... I know my tooltip is the product of dbPowerAmp, but I figured the rest was DOpus. Hmm.... Guess I should consider myself lucky:
[external image link broken]
Guess I just wanted to be informative. If not to you, then hopefully someone else will learn something. 
The tooltip image when hovering over a flac file is from DO (it is apparently displayed by default), but what I was referring to was that DO doesn't seem to give the correct value to the script through .Metadata.audio.coverart when querying a flac file.
Scripts might not have access to coverart that comes via plugins.
If you want us to look at it, please open a thread in Help & Support, as we don't keep track of questions posted to threads about scripts.