I'm starting to like this program. How do I get it to automatically play a playlist when I start it?

Start it with these options:
SYS:Utilities/Jukebox AUTOPLAY PLAYLIST=Path:To/your/playlist

I would like to see this as a tooltype or better: setting in the prefs. Because I always have to select it and it takes so long to load the playlist every time. Also an option to start playing at once would be nice.

Quote:
There is an option for it to start a chosen playlist when started, which I use.

If you run Jukebox, and then either double-click on the desktop icon or if you have set the program to display in the titlebar the track playing and the previous-track/pause-play/next-track icons in the titlebar of any MUI enabled screen, then you can right-click and select the Settings option, or open the player window, which will open the tracks that you want to play, and then select from the menu the Settings option for the program which will offer you the opportunity to start automatically when the program starts, and to choose a specific track to start playing, etc. - there are loads of options, and it is one of my favourite little programs for MorphOS, as I really like to listen to my favourite music when doing anything on my MorphOS system.

Hello!

Is it possible to integrate Jukebox to Ambient's mp3 sbar module?

I mean, it is would be nice to have a visual feedback from the song that is being played on screen bar by just double clicking a playlist or creating a newer one.

Just a though :)

> There is an option for it to start a chosen playlist when started, which I use.

I know this option. I meant: immediate playback, not only after reading ALL the playlist. This takes very long.

I think it would be good if you didn't have to re-read all the files in the playlist everytime you load it. With a couple of thousand MP3's it not only take a lot of time, it also make my HDD work very hard for no good reason. Just my 2 cents.

Quote:
I have about 1,000 mp3s in my main playlist and the first mp3 starts to play virtually immediately, on my Mac Mini 1.5GHz, though it does read through the playlist in its entirety, which only happens the once when you start it up, and considering all the other HDD head reads I must access during a session I don't consider the HDD accesses really that unnecessary, but others may decide otherwise.

I like the program, but it would be good for MorphOS to have it's own mp3 TAG editor, as I haven't noticed a good one for MorphOS, so I use the MUI based Amiga 68k MP3TagEditor - actually betatested by Jacek Piszczek - Jacadcaps, who is now one of the MorphOS developers, which works really well.

I don't see the point of adding visualisations - as used in some players, in any case they just annoy me, as music is an audio thing, not a visual one, unless you are watching a music video, then you want to watch it & hear it, so MPlayer is great for that.

As far as it goes, I think Jukebox works as well as you might expect for a basic audio player, though CD to mp3/wav,etc "ripping" might be a nice addition, but I use Code Audio for that which does the job really well, though it doesn't show/download album thumbnails, but it does download the CD title and tracks list and writes them to the tracks as it converts them, which is really good.

These 2 programs - Jukebox, and Code Audio, apart from the MorphOS itself, were part of the reason I registered my Mac Mini machine.

> CD to mp3/wav,etc "ripping" might be a nice addition

That's what Flacapella is for. It can "rip" to FLAC and WAV at least.

Quote:

Yeah, I don't see point including ripping functions to player programs, lets keep them separated. Flacapella can do encoding to any format with external encoders.

If you read Flacapella's .guide, you see examples how to configure external mp3 ripping.

At the simpliest form it's just like:
c:lame -V2 {input} {output}

I myself use this line to get all tags and cover images (if found from internet) embedded automatically:
Compress Command: c:lame -V0 --tt "{title}" --ta "{artist}" --tl "{album}" --tn {track} {?coverfile:--ti "{coverfile}"} {input} {output}
File Extension: mp3

Remember to have lame installed in SYS:C/

Quote:

The best option would be - as it is available in AmigaAMP - after the restart, the Jukebox should continue playing the playlist from the previously played song..

BTW. if someone wants to test my script to add files/dirs from Ambient to Jukebox via mimetypes:
http://jpv.wmhost.com/jpv_software/arexx/JukeboxAdder.lha
Preview pics:
jukeboxadder_dirs.pngjukeboxadder_files.png

I mostly keep Iconify option set and wide screenbar module enabled, so main window is hidden when I doubleclick mp3 files etc. I just control with screenbar..

[ Edited by jPV 09.11.2013 - 13:45 ]

Quote:

Jukebox is a stateless player. It does not keep history of played songs or list of songs.

Jukebox is scriptable at the start of playback and at the end of playback with Shell scripts. This behaviour is scriptable.

It still lacks some proper documentation for Arexx commands (mostly done but not included in ISO).

Quote:

It is the intented behaviour. File system is like a database and thus fits perfectly in this case.

About the loading time, my Mac mini is able to load 50 files per second with a 80GB 7200 rpm 2"5 disk. I think it does the job pretty fast enough imho. For 1K songs collection, it would takes 20s with my setup. I won't call this long.

If anyone has a nice collection of MP3 and a SSD drive, I'll be glad to get some feedback about the loading time with such setup.

Also, loading from a database would ask even more time: for each file stored in database, in a perfect world, the following two things should at least be done:
- Check if the file is still present, if not remove entry from database,
- Check if the metadata has changed (user tagged some songs) and update database content if needed.

With the current 'brute force' approch:
- Recursively walk a directory,
- If file is loadable with Reggae and type is sound, load it,
- ???
- Profit.

If songs are added/deleted/modified/moved etc, Jukebox still loads it right without having to mess with fail prone database stuff.

Also, keep in mind that Jukebox is meant to be a minimalistic player.

I had left commandline launching to that JukeboxAdder script and saved user settings weren't used that way. I updated it to use wbrun now and all settings should work.

Tcheko: indeed playback starts earlier now. I had to unset and set this checkmark again to have playback during scanning the library. But scanning the playback times still needs very long (20 minutes and more).

Updated JukeboxAdder again. MorphOS 3.4 allowed removing of the "wait 1" before playing and converting script to Lua language too. Lua can be used without any 3rd party stuff (like rexxsyslib.library with arexx).

Also converted MultiMeedio script to Lua. It is a script to control several different audio players with one script. You can assign it to multimedia keys and then they work with any player you happen to have running.

[ Edited by jPV 19.12.2013 - 17:32 ]

I think the approach for using just the path that you got is the best because then it doesn't matter if you removed, added, renamed a file or not. Jukebox will find it.
What seems to take most of the time is not the scanning for files itself but calculating their length. This takes hours (ca. 15,000 songs) everytime I start playing. For all this time the progress bar in window border runs and slows down the harddrive. And it got bigger, so it is more difficult to hit the close gadget. The smaller size was better.

Quote:

Actually, the progress bar should be there on the length field of every track, but MUI throws it to window corner if that field isn't visible. So, if you have bigger window or scroll where it's calculating, you get it away from the corner :) And bar's size depends your MUI settings.. it's small here.

Earlier there also was tooltype to disable calculating, but hmm.. I don't think it's there anymore.

> Actually, the progress bar should be there on the length field of every track, but MUI throws it to window corner if that field isn't visible.

Which invisible field do you mean? The last of the pre defined columns? It is activated but not in the visible area. If the progress bar is misplaced then it is a bug. OWB does not have this bug.
I see no sense in running through thousands of files and calcultaing their size. This can be done on loading the file *IF* it gets played but not as a precalculation.

> So, if you have bigger window or scroll where it's calculating, you get it away from the corner :)

I have never seen a gadget that got placed totally somewhere elsee just because I used another window size - which is the default size btw. And the usage of small windows is - to keep them small.

> And bar's size depends your MUI settings.. it's small here.

I only installed MOS 3.4 over 3.3. The skin stays the same but the bar is about 30% higher now.

@connor, about computing the 'size'.

This is not the size that is computed but the time length of the sample. This happens only in one case : VBR encoded MP3 without XING tag.

If your MP3 collection is only made of VBR encoded MP3 without XING tag, you should seriously consider adding this XING tag to remove the need of the length computation on startup.

I meant length, yes. VBR with or without XING: It is maybe mixed but no other player needs to recalculate the time for all songs. E.g. SongPlayer just plays the same library.

Quote:

Good for them then.

SongPlayer must keep this data somewhere in a file maybe ?

If you don't want Jukebox to compute VBR length MP3, add XING tag to the offending files.

Here is the benefits:
1. Jukebox won't add a mysterious file named database.to.store.vbr.length to your HD
2. (or) Jukebox will not silently mess you VBR files with some XING tag
3. Length data will be stored at the ** right ** place: inside the media itself.
4. Jukebox second loading step will be simply skipped as there is no more XINGless VBR files

Ha. And last point: The length computed by Jukebox is ** very precise ** for VBR.

Maybe other players do 'simple' math dividing the whole filesize by the VBR to get a rough estimation of the length. Quicker but dirtier.

SongPlayer and ANR seem to give quick and precise lengths for tracks, what I tried just. They don't write anything anywhere as far as I see. Maybe they use some simplier calculation which seems to be enough still.

Amplifier and AmigaAmp give lenghts totally off.

MPlayer is quick too and seems to be accurate.

[ Edited by jPV 21.12.2013 - 21:36 ]

Quote:
Doesn't look like this. I see no files that SongPlayer or AmigaAMP or other players create for that purpose.
Quote:
This is a huge effort and (as other players show) not necessary. What about a switch in Jukebox to disable that?
Quote:
Other players to not do so as well.
Quote:
That is indeed a valid point but Jukebox does not store anything in the played files, either. So when I throw the library to it next time, all lengths are calculated again.
Quote:
see 3. does not seem to work so far.
Quote:
Maybe. But who wants to look at the length of the tracks all the time instead of simply listening to the music? If the track length is miscalculated by some seconds, who cares?