Video Jukebox - download now available!

[Rebel Oz 69]

It's been quite some time since I've had anything to report, as for the last year or two things have been pretty hectic, but I've been gradually redeveloping/migrating this project over to a multi-platform environment in my spare time.
That said, this project is now at the point where I reckon it's ready (enough), so, (at long last), here it is!


As of now, the support for a secondary display is not enabled (who would have thought having two windows running in a single instance of Flutter would have been so tricky?), but that's the next major code change planned.


Some of the key changes over the prototype version:

• Licensing options:
• In the 'FREE Forever' version, the media library will be fully populated, but there will be a limit of 24 items made available. I figure that's what you got in a 'real' classic Jukebox, and for some, that'll be all that's needed. For those of us who want more, licensing options will be available on right-click menu.
• During the initial Public Beta stage, the software will 'expire' 90 days from release date. It will still be fully functional, but playback speed will be reduced (as a reminder to come back and grab the latest version). This limitation will be removed once the Beta phase is complete.

• Multi-platform support:
• While the initial release will be for Windows, we will release Linux and Android versions also (planned for early July).

• Video support:
• Now enabled: video skin support! You want to see the platter spinning and the colour tubes cycling? Well, now that's possible.
  Basic wallpaper support is ready to go.
         
         
• Zooming. When video media is playing in the 'mini display', pressing the 'BTN_ZOOM' key (mapped to 'Z' by default) will smoothly transition the video to full-screen mode (and back, by hitting the same key again).
         
         

• Touch Screen support:
• Full support for touch screen, with swipe gestures to navigate through song cards, tap to select tracks, etc.

• Colour Palette:
• The pre-defined (named) colour list now contains over 7000 items (though a couple hundred are aliases for a given colour value - eg 'Dark Gray' and 'Dark Grey').
  Can be viewed in 'ColourSwatches.html' (generated on demand by setting 'ExportPaletteSwatches' to true in the jukebox.ini file) in the program directory.
• Sortable by either HSV, Name, RGB Value, or Rainbow.
• Custom colours can be specified as 0xAARRGGBB (Alpha, Red, Green, Blue), or 0xRRGGBB.

• Metadata:
• We now have multiple metadata collection methods. If the first fails to collect any meaningful data, we try the second. If that doesn't yield anything, we try the third, etc. We then combine the results.
  Can be slow (especially on large video files), but usually gets good results. With good tagging of files though, it's SUPER quick.
• If 'UseID3' (metadata tag collection) is turned off (or doesn't yield useful info), we examine the filename.
  With well-named files (ie, 'AlbumName-DiskNumber-TrackNumber-Artist-TrackTitle') it's pretty fast.
• The framework is in place (though disabled) for MetaBrainz Identification of tracks.
  This will allow the creation of a unique audio fingerprint for each file, then look up that fingerprint in the AudioBrainz online database and retrieve the track information.
  Comprehensive, and quite accurate, but significantly slower to generate our index.
  Requires an active internet connection when creating the index.
• Improved filename parsing for better track naming.
• Improved cover image collection.

• Performance optimisations:
• Sorting media (which can now be by Album, Artist, Title, Type (audio/video), Random (to 'scramble' the song list), or Popularity) used to take many seconds - sometimes minutes.
  Now, it takes microseconds; eg. 3000-odd media items - 7 thousandths of a second. And that's sorting TWICE (eg, by Artist, then sub-sorted by Title).
• With checksum generation disabled (which is currently the default; we'll enable this for use with media de-duplication later), reading media metadata and populating the database is orders of magnitude faster.
• Startup is now complete in under 2 seconds (including skin loading time); Usually much quicker.
  For example, in testing I loaded the default skin, with no previously created database (so, populate from nothing), read and store info for 3319 media items, sort by Artist - took 43.6 seconds (including extracting and writing to file any MP3 cover art metadata) on my old core i5 laptop.
  Same scenario, same media, without the database generation: 1.04 seconds.

• Media card text sizes (for Artist or Track Title) can be either set for the entire collection, or per 'item'.

• By default, we'll be adapting the font size in real time to match the current content on display - to use every available pixel to the maximum, and allowing window resizing on the fly.

• Screen saver has had a facelift:
• Now with multiple options (Blank, Bubbles, Lines, Mondrian, Rain, Slideshow, Stars, Tron, Warp, or Random).
• As you see below, we can optionally also display cover art (where available) blended with the screen save effect.
• If no options are specified, a default configuration will be supplied.
• Media information is 'split', and each item (ie: title, artist, album, runtime) bounces independantly.
• Lines - A kaliedoscope using alpha blend modes for silky smooth transitions and fades, now also allows multiple lines at once, and an improved kaliedoscope effect (with adjustable segment count, rotation, speed).
  If you prefer the 'classic' look, that's still in there.
  
• Bubbles - Rising through the screen, reminiscent of a carbonated beverage in a glass...
  
• Maze - Draws a maze, and walks through the solution. Can also save the maze (with & without solution) separately.
  
• Mondrian - The classic random rectangles.
  
• Pipes - Various pipe-like structures built around the screen.
  
• Rain - My spin on 'Digital Rain' (Inspired by The Matrix).
  
• Slideshow - Display images in a folder of your choice, with sub-title.
• Stars - A twinkling night sky (coloured, or monochrome).
  
• Tron - Last light cycle left standing wins.
  
• Warp - A starfield rushing past as you trek along (coloured, or monochrome).
  
• Random - Pick a new one from the available list each time the screen saver activates.
• None - If you'd prefer no interruptions.
• A lot of options are customisable (editable within the 'Jukebox.ini' configuration file), with more coming soon. Also, we've added a (removable) button the the 'lines' screensaver, to access options with 'point and click' functionality.

Some things that aren't quite right yet:

• Media overlay:
• Currently we're not displaying the media overlay information (at least, not in the way the settings in the ini file were designed for) - this will be added after we have dual monitor support fully operational.
• Media waveform / graphic equaliser - disabled while we get dual screen working.

• DW-Juke Skin options:
• DW Juke skins should read in fine, but some things have been deprecated, and other things (like skin timers, for example) have not been implemented (yet).
  Check out the included skins for examples.
• INI file processing is much more robust, and should handle most things case insensitively.

• Skin swapping:
• The key action bindings are there, but real-time transition between skins isn't quite ready for prime time - it works for SOME things, but it's not all fully baked yet...

• Selector Keys:
• There are still a few issues with mapping the displayed key combination to select a song on Dual-track cards. For now, best option is to click/tap the item (or highlight it using cursor and selecting it that way). Doesn't appear to be an issue with single-track cards. - working.

• Skin Editor GUI:
• This will not be available for some time yet, but it is on the roadmap...

• Show Keys

The link should get you the V0.959b download; please let me know if you have any difficulties.

Please note, this version of the program is run with the 'StartJuke.bat' in the app directory (not the 'obvious' icon). Just uncompress it all wherever you like and run that (If you don't provide a configuration, one will be created for you, or copy in your old DW-Juke config.ini & jukebox.ini - it should 'kinda' work...)

Configuration is (like the awesome DW-JUKE) via the jukebox.ini file, so set your songpaths and other things by editing that file (if you can't find it, run once and exit, then it'll be there in the main program directory).

The program linked below is fully functional, with the limitation that it will only use the first 24 tracks in the library; please contact me if you'd like to acquire a license to remove this constraint. I'll be setting up the email address shortly, so in the meantime, PM me here.

One final thing; this version relies on Visual C++, so you'll need to have the VC Runtime (from Microsoft) installed to run it.

Link below. Enjoy!


https://drive.google.com/file/d/1SYoj1yL6aEQeaHM80gn2URMVwDD_KMjW/view?usp=drive_link
[/list]

[Rebel Oz 69]

It's my brother's birthday today, so to celebrate, I'm releasing an update!

This version has a few more bugs squished, so Next/Previous Alpha buttons work properly, along with improvements to sorting algorithms and better font handling for legacy skins.

The 'Popular' display is also much better (behaving more like you'd expect), so now, all the buttons on the 'Default' skin work properly.

The most exciting change, though: skin-swapping now works MUCH better, with transparency on the strip grid, strip cards and icons changing properly, and a notification popup displaying the skin info (which can be disabled in the jukebox.ini if you prefer).

Download it here:
https://drive.google.com/file/d/1G9LlpljCa0_PFu3acWk0PpZ2qXVmYInw/view?usp=sharing

[Rebel Oz 69]

Another update, with some major performance improvements.
Skin swapping is now almost fully complete.
Song selector enabled, with (customisable) focus box.
'UseZero' skin option now works correctly.
Screen saver now much smoother.
Quite a few little bugs fixed.

We've switched from G-Drive to using a OneDrive folder for uploads.

Comments and suggestions welcome.

Download here:

https://1drv.ms/u/c/0e0ef07ab6aa89ee/EYhP_q0cePZCisz6017O5FoBhp6IDcmGZyh52EM6qjWJFA?e=hFQcLG

[Rebel Oz 69]

A quick update (V0.962b) to fix an annoying bug I introduced, where the 'Coming Up' message icon was prevented from being displayed.
I've also changed the method for updating texts in all displays, to populate the displays even if not currently visible (so when they become visible, they have correct values already prepared) - marginally quicker.
I've also tweaked the mini-media display transparency, so if no video is playing, the queue / popular lists display more clearly.
Also fixed the sound-effect volume calculations, so sound effects should now more accurately respect the jukebox.ini volume settings.

Link here:
VideoJuke - 0.962b

[jonrome]

HI, I have VideoJuke running happily, how do I upgrade to remove the restriction please? When I right click I get the form but it won't allow me to enter any details.
Thanks
Jon

[Rebel Oz 69]

HI, I have VideoJuke running happily, how do I upgrade to remove the restriction please? When I right click I get the form but it won't allow me to enter any details.
Thanks
Jon

Hi Jon,

Glad you like it!

I've sent you a PM - looks like the form handling code has gotten broken along the way; I'll fix that and upload an update, then be in touch to make sure it works properly.

[Rebel Oz 69]

A quick update (V0.963b) to fix another bug I introduced, where the optimised code for handling dialog borders prevented the Registration Information dialog from holding keyboard focus (thus preventing typing).

Some other changes:

• Addition of a few new Dual Strip card variants (simple plain labels, with a couple of colored lines for Artist in the middle).
• Optimised display writing (so screen updates are performed much faster now).
• Improvements to keyboard buffer handling.
• Fixed error where under some conditions, the snackbar dialog would display (even when disabled).
• Added ability to dismiss snackbar notifications by clicking/tapping anywhere on-screen.

Link here:

VideoJuke - 0.963b

[Rebel Oz 69]

Another update (V0.964b).
Some of the changes in this release:

• License activation request handling now works. Now when you right-click, enter your details & hit Save, an activation request (activate.txt) will be created in the program directory. PM me for further info.
• In-progress selections are now preserved during skin changes.
• Improved performance of display position/size/text/color updates.
• Skin change: Now updates all display text correctly.
• Skin change: Next/Previous button functionality improved.
• BTN_CLEAR_QUEUE: Now clears down correctly (ie. only to the item after the currently playing item), preserving previous item history.
• Added 'Instant cancel' capability to Snackbar notifications.
• Fixed auto-dismiss functionality for the version display dialog box.
• Improved some logging labelling.
• Added Selector 'Marching Icons' border effect (not yet wired up).
  
  
• Various code cleanups and optimizations.

Link here:

VideoJuke - 0.964b

[Rebel Oz 69]

Another small update (V0.965b).
Some of the changes in this release:

• Fixed: Skin change issue, where number of lines per sub-display wasn't reset reliably.
• Fixed: Skin change issue, where maximum skin number was off-by-one (so highest number skin would be skipped when changing skins).
• Fixed: Bundled skin 'Stereo-Touch' name typo in jukebox.ini.
• Fixed: Alpha-numeric search function now works correctly (if key pressed is not a selector key).
• Fixed: Sometimes screensaver would be closed if a snackbar was dismissed at the wrong time.
• Fixed: Master Volume value now logged correctly.
• Added: Direct skin change keys (ie BTN_SKIN_1..BTN_SKIN_20) to jump straight to the numbered skin.
• Added: Conway's 'Game Of Life' simulation (life) screensaver (because, why not? It's only a couple hundred lines of code).
• Refactored startup sequence to improve performance.
• Refactored Player Event handler to improve performance.
• Optimized media metadata retrieval (on average, about 25% faster when indexing).
• Tidied up skins to optimize strip grid usage.
• Bug Hunt: The very first track played at startup sometimes causes track information snackbar to appear twice (if snackbar is enabled and Radio Mode is enabled).
• Bug Hunt: When resizing screen of changing skins, if track title is long, scrolling functionality gets messed up.
• Bug Hunt: When changing skins, Mouse-over Tooltips are not updating correctly.

Link here:

VideoJuke - 0.965b

[Rebel Oz 69]

Another update (V0.966b).
A massive re-write of large sections of the code, along with some key structural changes behind the scenes.
Some of the changes in this release:

• Added: Display management sub-system (for upcoming multi-screen mode).
• Added: Long Press now opens Options Menu.
• Added: Auto-hide mouse cursor functionality.
• Added: Option to blink the credit display if you have zero credits available.
• Added: Waveform / graphic equaliser display for audio-only media.
                                 
          Supports zoom to full screen, with configurable transparency (By default, "KEY_SLASH_PAD" = "BTN_TRANS_DOWN" and "KEY_ASTERISK" = "BTN_TRANS_UP").
          This allows full control of the media selection, whilst still displaying the visualiser.
• New Option: Jukebox.ini > settings > 'VisualiserMode' allows you to select an audio visualiser mode.
           Valid options are: Waveform, Bars, Zoned, ZonedLED, and None.
• New Option: Jukebox.ini > settings > 'WaveColor' allows you to pick the color used to display the waveform.
• New Option: Jukebox.ini > settings > 'BlinkCredit' allows the new credit blink function to be disabled.
• Fixed: Annoying flicker when mouse enters/leaves media player zone has been resolved.
• Fixed: Wallpaper video no longer restarts when UI is rebuilt (No more flicker).
• Fixed: Tooltips now update correcty when skin changes.
• Fixed: Long title scrolling. Now pauses for 5 seconds before looping. Also fixed resizing glitch that caused text to be displayed twice sometimes when resizing.
• Fixed: Bug in duplicate checking.
• Fixed: AutoScreenSaverCancelTimeout option should now work correctly.
• Fixed: Snackbar queueing system more intuitive.
• Fixed: Bug where screen saver was cancelled if next media is video.
• Fixed: Mouse hover zones no longer appear on non-clickable icons.
• Refactored: DW Display build logic (In preparation to better handle multi-screen).
• Refactored: Screen Saver trigger/cancel logic - now has a state manager for more precise control.

I'm particularly pleased with the audio visualiser, which required a re-write of the entire playback state management sub-system. As I could find no way for the video player component to expose raw waveform or FFT data for audio stream analysis, I've split audio-only media and videos into their own stream handlers. The re-design makes the media handlers much more modular, and the logic is much cleaner and more efficient in the backend now. This has also paved the way for audio beat detection (not currently exposed).
There's one limitation though: M4A (AAC in MP4 container) is currently not decoded in the audio-only engine, so it will be treated as a (blank) video.

The improvements to snackbar handling make it much nicer. We now prevent duplicate consecutive notifications, with the ability to auto-cancel any snackbar being displayed, which makes it feel way more responsive/timely.

Refactoring the DW Display build logic has yielded a nice performance gain, especially when screen saver activates. We now preserve UI state in the background, but prevent unnecessary rendering (improving screensaver rendering speed), and when screen saver closes, the UI is already built and ready, which makes resuming from screensaver lightning fast.

We've also optimised the icon build process, so each icon is only ever rebuilt if it's actually changed.

All combined, these changes nett us around a 20% improvement in UI creation times, so skin changes are super quick, but there's an issue I'm tracking down with the orientation/scaling logic (affecting media player window on some skins) when skin changes right now, so I'd advise against using it for the time being.
This will be fixed for the next release.


One final note: The licensing routine has been updated, which means we will need to re-issue licenses for those who have purchased the application.
Please contact me for a replacement license.

Link here:

VideoJuke - 0.966b

[Rebel Oz 69]

Well folks, this is the moment we've all been waiting for: MULTI-SCREEN MODE is here at last!



Some of the important changes in this release:

• Added: Multi-screen mode. If enabled, the system will use your (user-defined in jukebox.ini) primary display as the screen for interaction, and auto-select the largest available secondary display for displaying media / audio visualization.
• Added: Improved logging. In the process of modernising to use emojis for easier identification of key processes.
• Option - moved: Jukebox.ini > Settings > 'PrimaryDisplay' has been discontinued, and has been relocated to Jukebox.ini > Display > 'PrimaryDisplay'.
• Option - moved: Jukebox.ini > Settings > 'SingleScreenMode' has been discontinued, and has been relocated to Jukebox.ini > Display > 'SingleScreenMode'.
• Fixed: Skin swapping is now fully functional, and performance has been dramatically improved when switching skins.
• Fixed: Skin background video metadata extraction now yields accurate video dimensions (if available). Will assume 1080P if metadata is not present.
• Fixed: Selecting 'Windows' for your screensaver now works properly (if one is defined at system level).
• Updated: The skin files have had a little long-overdue maintenance. Improvements to scaling logic have enabled more accurate positioning of skin elements.
  The 1015 skin has had a bit of a cleanup, and sub-screens / Strip Grid repositioned to reveal more of that iconic beauty.
• Refactored: Strip Grid and Icon Deck performance optimisations.

With the arrival of multi-screen mode, there are a few points worth noting.

As shown above, we've moved a couple of display configuration options in the jukebox.ini file (from 'settings' section to 'display' section), as that seems the more logical place for them.
These two options are now fully active, and are the key to customising the app to suit your personal display configuration.
If you're using an older ini file (ie, one without these options in the correct place), please be aware that the system will default to using the two largest displays (where available) if those options aren't found.

If no secondary display is found, we'll (obviously) revert to single-screen mode.

You can always enforce single-screen mode if you wish, by setting 'SingleScreenMode' to true in the jukebox.ini file, which will still respect the PrimaryDisplay setting.
This will still enable the mini-display visualizer for media playback (or not, it's your choice), just as before.
    Eg.

In multi-screen mode, the BTN_ZOOM function serves no purpose, so it is disabled.

There are no limitations on display size/positioning/orientation - there's no need to 'tweak' your monitor configuration at system level. We'll detect and adapt to suit, and exclude any mirrored displays. If your graphics card will handle two 4K displays, so will we. 

In single-screen mode, orientation changes will reactively update the app layout (ie, if you're using a Windows tablet, rotating the screen between portrait and landscape mode will work, on the fly).

If multi-screen mode is activated, fullscreen mode is automatically activated, and the 'Toggle Fullscreen' option (in the right-click options menu) will not be shown.

Screensaver (if enabled) will only affect the primary display. Any media playing on secondary will continue to play uninterrupted when screensaver activates.

When there are two or more monitors attached to your system, here's how we handle it:
  *  Your primary monitor is selected (either by specifying it in the ini file, or by being auto-selected as the largest available).
  *  From the remaining monitors, the largest available is elected as the secondary. If more than one exists, the lowest numbered (by the system) will win.
  *  The application sets up the 'master' window, to cover all the screen real-estate between the two displays. So, if (for example) you have three displays, and you specify the rightmost one as your primary and the system selects the leftmost one as your secondary, the app window will 'blank' any intervening displays.
    Eg.

Just as before, any mouse pointer currently active on your system will be automatically hidden if it is positioned over the media playback.


Notifications:
  *  Notifications for media information will be displayed on the secondary display (if enabled, otherwise we'll use the primary display).
  *  Notifications for other information (eg. Pause/Resume/Screenshot saved, etc.) will be displayed on the primary display.
  *  Setting 'NotificationsEnabled' to false in jukebox.ini will turn off ALL notifications.
  *  Tapping/clicking anywhere on either display will automatically dismiss the current notification.


Since the startup sequence has been updated to query the Operating System for display information and calculate the desired layout, startup time may be slightly longer than previously, but should still be no more than a couple of seconds.


Note: If you haven't updated since V0.965, please be aware that the licensing routine was updated in V0.966, which means we will need to re-issue your license.
If this affects you, please contact me for a replacement.

Download here:


VideoJuke - 0.967b - Direct from sublimedesign.au

VideoJuke - 0.967b - Backup link (OneDrive)

[Rebel Oz 69]

Changes in this release:

• Added: Option: jukebox.ini > TitleStrips > 'Animation' is now active, to enable Strip Grid page change animations.
• Added: Option: jukebox.ini > TitleStrips > 'AnimationCascade' to enable user-configurable custom delay time between card swap animations.
• Added: Option: jukebox.ini > display > 'HideDesktopIcons' to enable (you guessed it) hiding all desktop icons while the jukebox is running.
• Fixed: Duplicate event processing on mouse scroll events (ie, scrolling TWO pages forward instead of one when using mouse wheel to navigate pages).
• Fixed: Artist font color not updating correctly on skin change.
• Fixed: F10 handling in Windows version - no longer intercepted by Operating System to activate app menu.
• Updated: 'ShowKeys' option revised to include mouse activity.
• Updated: Moved all DLLs out of main directory, adjusted search path to find then in data/lib. Makes the app folder much tidier.
• Updated: Splash screen at start-up now fills screen.
• Updated: EXE file properties now show correct build info.
• Refactored: Strip grid cards now leaner and faster.
• Refactored: Navigation keys now unified to sync with page change animation handling.
• Refactored: Rainbow border now evenly distributes colors, with smoother timing.

In this version we introduce the page change animations you may be familiar with from DW Jukebox (FlipHorizontal, FlipVertical, SlideHorizontal, and SlideVertical, or None), along with a few new options:

• 'Fade': Fade out the old card, fade in the new card.
• 'Scale': Shrink the old card, then expand the new card.
• 'Cylinder': Similar to Flip, but more like a classic 'reel'.

In addition, the delay between card 'flips' is user-configurable (by adjusting 'AnimationCascade'), so if you prefer to have the cards flip in sequence rather than all at once, you can set the delay between each card swapping for a more aesthetically appealing experience.

Link here:

VideoJuke - 0.968b
VideoJuke - 0.968b - Backup link (OneDrive)

[vampire]

Hi, firstly congratulations on reprogramming DWJukebox and adding all the new features, must have taken ages. I've been using DWJ for years and it is the only jukebox software capable of displaying a single titlestrip as it would appear on a real juke box. I.E. Artist in the centre with the "A" side on top and the "B" side below (and it takes a bit of effort to get this to work). It would seem your program can't do this, I spent quite a bit of time with "Fruitbox" on the raspberry pi and had the same issue. I don't know why this isn't a primary feature in any jukebox emulator, there's little point making a program that looks like a jukebox if it doesn't function like one. I can't be the only one who wants to see the A and B sides correctly shown.I would be happy to support anyone who can get this working. In DWJukebox it works by sorting by filename rather than ID3 , the program takes the filename as the song, the folder it is in as the album (which is ignored in a singles jukebox) and the folder above as the artist. The singles are therefore in folders arranged - ARTIST with 2 subfolders X1 and X2 with the appropriate songs in each folder. Because X1 comes before X2 alphabetically the program sorts them correctly. (X is the single title).  This is from the ini file.

# If SongSort is set to Artist, title strips will be sorted
# by the artist name. If SongSort is set to Random or is not
# set, title strips will be randomized. If SongSort is set
# to Album, title strips will be sorted by the album name.
# Note that Album sort only appllies to CD-based skins.
# The default is Artist.

SongSort = Random

Your program allows album sort in singles skins not just CD skins, not sure why, in any event titlestrips are hopelessly mangled. Hope you can sort this out,  it would be fantastic to have a modern version of this classic program but it is a deal breaker for me not to have the singles correct.

[vampire]

I should have mentioned, the INI file refers to "Songsort" but it is actually the title strips that are sorted by this, the title strips are generated by the programs own logic based on the folder structure, this option should really be called "Titlestripsort" as it is the complete titlestrips that are randomised or otherwise sorted.

[vampire]

I've experimented with renaming files using the split5 format and can tidy up the titlestrips somewhat, by sorting by album I can get the 2 sides of a single in the same titlestrip but not listed correctly, if the program had a second sorting parameter it may then work (Album, Track No.) Ideally the titlestrips would be generated and then randomised as done in DWJukebox.

[Rebel Oz 69]

I've experimented with renaming files using the split5 format and can tidy up the titlestrips somewhat, by sorting by album I can get the 2 sides of a single in the same titlestrip but not listed correctly, if the program had a second sorting parameter it may then work (Album, Track No.) Ideally the titlestrips would be generated and then randomised as done in DWJukebox.

Hi Vampire, and thank you for your feedback!

Firstly, my apologies for not responding more quickly; it's been quite hectic here recently.


The primary reason the ini option is called 'SongSort', is to preserve a level of backwards file structure compatibility with DWJukebox, but the underlying logic is:

1. If the database is empty or invalid (or the 'UpdateIndex' option is set to true), we read in all the available metadata for each track, and build the database. If ID3 metadata is not sufficient to uniquely identify the track (or is disabled), we apply the selected 'FilenameCrop' option (ie, Split5/Smart, etc.).
2. Apply the selected sorting algorithm, based on each individual track's metadata.
3. Display the title strips.


If I'm visualising this correctly, your file system structure is:
    ArtistName
      └- Album1
        └-   Track 'A' Title
      └- Album2
        └-   Track 'B' Title

And your skin.ini file specifies 'SongsPerStrip=Double'.

To 'tie' two tracks together, the album title is used (currently), which (in the example above) would be two similar (but not identical) albums, resulting in a loss of fidelity (assuming we were to rely on the folder name to contain the album name, which we don't do at this point).

If (on the other hand) your track filenames contain ALL the relevant data in Split5 format (ie, album name - disk number - track number - artist - track title; eg: "Singles-01-01-John Denver-Take Me Home, Country Roads.mp3" for the 'A' side, and "Singles-01-02-John Denver-Thank God I'm a Country Boy.mp3" for the 'B' side), regardless of where they're stored in the filesystem, the correct relationship should be in no doubt.

Obviously, my assumption is that, for a single, track number 1 will be the 'A' side, and track number 2 the 'B' side.


So, if (for whatever reason) the track numbers aren't accurately read in during metadata parsing, this relationship will not be stored correctly, and the sorting step will yield inconsistent results, causing the title strips to appear jumbled.


Your suggestion is completely valid, and I'll be reviewing the code for filename-only based metadata creation and sorting methods.

To date, this hasn't been much of a personal priority, as I spent considerable time a few years back running my collection through MusicBrainz Picard to update the ID3 info on every track, and have been focused on ensuring ID3 info works reliably.

I agree completely that it's VITAL to be able to display singles as singles (with A/B side preservation), so I could easily add a 'FileFolder' option to the sorting methods (or maybe just enhance the 'Smart' FilenameCrop method?), to ensure singles are treated as a discreet unit (even when randomly sorted) - the caveat being that the file system would be required to match a highly structured layout and naming convention, which may be fragile and difficult to detect/maintain/enforce.


Also, you're quite right to point out the inaccuracy in the ini documentation regarding Album sorting - that's a holdover from a previous strategy. We always allow Album sorting now, precisely so that singles are grouped together whenever 'SongsPerStrip=Double' is set.

From the latest ini file:
    ; If SongSort is set to:
    ; Album: title strips will be sorted by the album name.
    ; Artist: title strips will be sorted by the artist name.
    ; Popularity: sort by playcount, in descending order.
    ; Random: title strips will be randomized.
    ; Title: sort by song title.
    ; Type: sort Video tracks from Audio-only tracks (Video first).
    ; Unsorted: Tracks will appear in the order they're stored in the database.
    ; Note that Album sort no longer only applies to CD-based skins.
    ; The default is Artist.
    SongSort = Artist


Hope this helps.

[vampire]

Many thanks for that detailed response, it's clear there's more options in the software than I realised, I will experiment further and report back! I'm going to stick with file/folder sorting, I've no faith in ID3 tags, have tried repeatedly in "Fruitbox" and found issues, not least because there is no single tagging protocol and of course older files are tagged according to the whims of the original ripper. It would take a lot of work to standardise all my files, easier, in my case at least, to sort the files into appropriately named folders. Will have a play later today.

[Rebel Oz 69]

Many thanks for that detailed response, it's clear there's more options in the software than I realised, I will experiment further and report back! I'm going to stick with file/folder sorting, I've no faith in ID3 tags, have tried repeatedly in "Fruitbox" and found issues, not least because there is no single tagging protocol and of course older files are tagged according to the whims of the original ripper. It would take a lot of work to standardise all my files, easier, in my case at least, to sort the files into appropriately named folders. Will have a play later today.

That being the case, my suggestion would be to double-check the filenames in your collection, to verify they match the Split5 format (regardless of which folder they're in) - that way, everything should work as you'd expect.


If you *did* ever decide to take the plunge with ID3-style tagging though, I'd highly recommend giving Musicbrainz Picard (https://picard.musicbrainz.org/) the task.

If you haven't seen it before, you'll be amazed - it does an excellent job, and saves a HUGE amount of time; each track you feed it has it's unique audio 'fingerprint' detected, which is then compared against the Musicbrainz database (38 million recordings and counting), and the tags are auto-populated/updated for you, which you can then write out to disk. It can also move/rename your files into the right folder structure (if you wish). It's not perfect, but any (rare) 'misfires' can be easily manually edited/corrected, and then written to disk. This gives you the best of both worlds - track filenames are consistent and neatly organised, and the metadata is far more extensive (and predictable) than could ever be derived from a simple filename.

The added bonus is that once your tracks are tagged, you can then apply whatever file/folder naming convention you like across your entire collection with minimal effort, and if you change your naming convention down the track, it's trivially simple to apply the new style. One and done!

If you've got more than a few hundred tracks to sift through and validate/rename/update, Picard will save you many, many hours.

No, I'm not affiliated in any way with Musicbrainz; I simply love their work.

[vampire]

Hi, Spent quite a bit of time with this today, I've renamed a small number of songs using the Split5 format and although they will sort into the correct singles the sorting into the "A" and "B" sides doesn't work, there doesn't seem to be any particular logic at play! As for using ID3 tags how would that work in order to sort into singles? You say the tracks would be grouped by album but the 2 songs we need could have come from different albums initially and even if we change the tags manually we would have the change the track no.s too in order for the program to sort correctly, really can't see that being any easier then a filename system. BTW  I do like the Split 5 idea, it saves a bit of folder creation although in my case each song has to have it's own folder as I have the single label as artwork that is displayed as the song plays and that has to be in the same folder as the song. (Wouldn't want embedded art from the ID3 as that would be the album cover). All in all I think I better stick with DWJukebox as it does work for me just a pity it doesn't support Flac or Video but I can live with that, thanks for the response.

[Rebel Oz 69]

Hi, Spent quite a bit of time with this today, I've renamed a small number of songs using the Split5 format and although they will sort into the correct singles the sorting into the "A" and "B" sides doesn't work, there doesn't seem to be any particular logic at play! As for using ID3 tags how would that work in order to sort into singles? You say the tracks would be grouped by album but the 2 songs we need could have come from different albums initially and even if we change the tags manually we would have the change the track no.s too in order for the program to sort correctly, really can't see that being any easier then a filename system. BTW  I do like the Split 5 idea, it saves a bit of folder creation although in my case each song has to have it's own folder as I have the single label as artwork that is displayed as the song plays and that has to be in the same folder as the song. (Wouldn't want embedded art from the ID3 as that would be the album cover). All in all I think I better stick with DWJukebox as it does work for me just a pity it doesn't support Flac or Video but I can live with that, thanks for the response.

Hi Vampire,

In those situations where your original track metadata determines that two tracks are from different albums, but you wish to sacrifice track naming fidelity in favour of singles groupings, you're correct in thinking you'd need to manually edit the Album name (ie, rename the album to 'Singles', and set the track numbers to 1 and 2), and set the SongSort option to 'Album'.

The 'Random' option is not your friend here; it will (by design) scramble each and every track individually (ie, no album or artist grouping), so there's no way it would display singles with correct A/B information.

The problem has always been that, if a 'B' side doesn't exist (which should probably NEVER happen in a 'real' jukebox), we have no clean way to enforce that.
DWJukebox simply leaves the 'B' side of the title strip card blank. I opted to just add the next available track (possibly from a different artist) instead, and concatenate the two artist names (separated by a slash) to the Artist section of the title strip.

Example:


Not as elegant, perhaps, but my goal was to avoid blank title cards getting scattered throughout the system, to ensure track selection performs consistently (ie, the only time a blank card needs to be displayed is on the last page, and cannot be selected).

You've given me an idea though: I could add a 'RandomSingles' sorting option, which would add an extra check when randomising the title strips (but only if 'SongsPerStrip=Double' was set), and leave 'B' sides empty if no corresponding track is found.

I've added that to the Roadmap.

[vampire]

"The 'Random' option is not your friend here; it will (by design) scramble each and every track individually (ie, no album or artist grouping), so there's no way it would display singles with correct A/B information."

Correct, your system deals with individual tracks, as you acknowledge in a real (singles) jukebox there are always 2 sides to a single, randomising songs is pointless you need to randomise the "single" I.E. the titlestrip with the A and B sides  already allocated, this is what DWJukebox does (even though it is labelled "Songsort")

" I could add a 'RandomSingles' sorting option, which would add an extra check when randomising the title strips (but only if 'SongsPerStrip=Double' was set), and leave 'B' sides empty if no corresponding track is found."

Why would you create an option to leave "B" sides empty when you admit that would never happen in a real jukebox? the answer is surely to have a system that enables singles to display correctly. I understand that you are trying to appeal to many people who will have varying methods of storing their files but if your goal is to have a program that actually emulates a real jukebox there will have to be some input from the final user in terms of arranging files. Loading a real jukebox with new singles involves arranging the records in the correct place and typing and changing the titlestrips, it was a time consuming business and no amount of programming is going to create a perfect program that automates this. Better to have a side program to create "singles" that people can populate manually with the tracks they want. DWJukebox can do what I want, It took me quite some time to figure it out and involved a fair bit of work on my part to create the correct storage of the tracks in order for it to work. it is probably the case that I am in a tiny minority in wanting an accurate looking display, the people who actually remember real 45 jukeboxes are getting rarer by the day. Good luck with your program, but is it clearly not for me.
 

[Rebel Oz 69]

Why would you create an option to leave "B" sides empty when you admit that would never happen in a real jukebox?

Hi Vampire,

My recollection is that DW Jukebox does exactly that (if the 'B' side is not present), which makes sense when you think about it - if the user hasn't added the 'B' side to their collection, the software needs an effective coping strategy. DWJ's design is masterfully coded, but when I was planning out my application, I didn't want to deal with blanks interspersed throughout the interface, so I came up with the concatenation strategy (primarily because the programming language I was using at the time of that decision wasn't able to cope gracefully when sorting large collections with unexpected 'gaps'. The current language and architecture should be much more performant, so it may now be worthwhile revisiting).

Of course, like yourself, in the days when I still used DWJ I would always ensure my 'live' collection had matching A/B tracks (so as not to display empty slots), but I have no way to ensure that all Video Jukebox users are as OCD about that as I am!

Still, I think the 'enforce two tracks from the same platter per title strip if user requests it, regardless of actual collection content, and maintain that grouping even if randomly sorted' option certainly has merit, which is why I've added that to the Roadmap.


Having said that though, the detail derived from each track's metadata is always going to play a huge part in how tracks are laid out in the interface.
DWJ worked incredibly well at extrapolating that info simply from file/folder naming conventions, but my focus has to this point been primarily on using the more extensive and predictable ID3 metadata (for optimum performance when indexing large collections, consistency across alternate playback platforms like Linux/Android, ease of porting my old code base to a new language, etc.).

In your particular use-case, though, that's not going to be the option of choice, so I'm happy to work directly with you to come up with a suitable solution, if you wish.
I've sent you a PM with details.


Of course, if you would rather just stick with the ol' faithful DWJ and forego the extra capabilities now that you have it 'tuned' to your taste, that's also a perfectly valid decision. It still stands as an amazing piece of software engineering from the earlier DOS/Windows era, even with the inherent limitations.
I've taken a fair amount of care to try to make Video Jukebox as backward-compatible as practicable (ie, the provided jukebox.ini files should work with DWJ as should skin files, just without the extended options; Video Jukebox should work fairly well with DWJ jukebox.ini files, skins, etc.), but it's definitely still a work-in-progress, and some of that compatibility is currently incomplete (DWJ Timers spring to mind).



And just for the 'record', as a child of the late 60's, I absolutely agree that those of us with fond memories of our old 45s are a dying breed.
The first record player I ever bought with my own money was a second-hand 3-in-one deal - album-sized record player under a nifty lid on top (45, 33, and 78 RPM!) with manual needle drop, radio (AM only, of course), and a HUGE 18-19" CRT TV (black and white, it goes without saying), all in the one beautifully polished wooden cabinet. REAL timber, not the modern 'equivalent'. Weighed a tonne, but it was the best 49 bucks I ever spent.

It's in homage to that deadly old monster that I've included a feature in VJ that I hope few will ever actually see - if there's any serious error during program execution, the screen will faithfully reproduce a vintage TV Test pattern (in full TECHNICOLOR, along with the test tone) containing diagnostic info for a few seconds before switching to 'static' (complete with white noise) while it tries to recover. Failing that, it will 'shrink' the static to a dot in the centre of the screen (just like a classic CRT) when you exit. Currently hard-coded to display the PM5544 test pattern from my region, but the bones are there to display others (like the RCA Indian) as well...

[Rebel Oz 69]

Hi Vampire,

Thank you for your assistance in troubleshooting the issue you encountered with singles-mode sorting.

I'm relieved that the issue was resolved by moving the folder into your VM's local storage, but also grateful that we worked through this, as it revealed a bug with the database creation routines - with network storage, subtle timing differences would possibly cause track numbers to be incorrectly stored into the database, which would not have been apparent to me without investigating the file-name-based method (as opposed to ID3 method).

I've incorporated the fix into the latest (v0.969) codebase, which is due for release very soon now...