Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Skinjob

Pages: 1 23
16
I originally posted this in the General forum in April 2015, but thought I should re-post it here to keep it on the radar to hopefully be fixed.

Original post: http://getmusicbee.com/forum/index.php?topic=15518.msg92188#msg92188

-----------------------------------------------------------------

I've been using the portable sync features for a long time and have always found them to be excellent (the best I've seen).

My main library is all FLAC and I transcode to MP3 for portable use.  Normally I sync to an <AlbumArtist>\<Album>\<FileName> structure with M3U playlists as the primary way I use my portable devices, especially in the car.  And this has worked beautifully in the past.  However, I recently got a new car and unfortunately the USB support is shockingly bad: unusable navigation and no playlist support.  So, the only workable option is to use a folder per playlist structure.

I was very happy to see MusicBee had this option, but noticed a couple significant issues after using it:

1) When using the "folder per playlist" option, the encoding doesn't respect the number of threads option.  I have the encoding threads set to 4 to utilize all my cores, and with normal syncing this works as expected.  However, with the "folder per playlist" option it only encodes one file at a time.  I didn't think this was that big of a deal at first, as I only expected it to matter for the initial sync when I was loading 1000's of files.  However it exacerbates problem 2 on every subsequent sync.

2) Once you've synced the device, subsequent changes to the playlist in MusicBee can cause the entire playlist to have to be re-encoded the next time you sync.  I guess this is because the hard-coded file name format includes the playlist track sequence number.  So if you insert a track at the beginning of the playlist, all subsequent tracks get a new sequence number, which I guess causes MusicBee not to recognize that the files are already there, causing them all to be re-encoded and copied again on the next sync.  This is really a drag, especially when combined with problem 1, as it can take a very long time to re-encode long playlists.  It seems like it should be possible to recognize which files are already present on the device regardless of sequence, rename them with the correct sequence and then only encode new/changed tracks.

17
TheaterMode / Re: Gallery tag interval not working?
« on: September 17, 2015, 06:56:38 PM »
Sorry for the delayed reply - super busy at work lately.

So of course now that I've gone to the trouble to post about the problem it's started working again.  :)

The same artist that it was only showing a single picture now rotates through multiple.

But I swear I'm not crazy.  The staying on a single picture really was happening, and not for the first time.   And glitch with the track timer at the gallery interval seconds really was happening as well.  I rebooted for window updates shortly after this post and maybe that cleared something up.

I'll keep an eye on it and post if happens again.

18
TheaterMode / Re: Gallery tag interval not working?
« on: September 08, 2015, 02:02:45 AM »
I noticed that the track timer pauses briefly at the gallery interval and then resumes, in my case every 15 seconds.  Seems like maybe it's trying to do something and failing.

19
TheaterMode / Gallery tag interval not working?
« on: September 08, 2015, 01:38:47 AM »
Is it just me or does the Gallery tag not rotate images anymore?  I thought I noticed it a while back but never really confirmed it until recently.  Artists that I know for sure used to rotate multiple images now just stay on whatever image is fist downloaded.  I'm on 2.5.5721 now, but I think it started in one of the 2.4 patches.

It seems to be true on any of the canned theater modes that use the Gallery tag, but I use a minor tweak of the Artist Pictures one with the following Gallery tag:

<element type="Gallery" x="1" y="1" widthDock="Panel" width="-2" heightDock="Panel" height="-2" aspectRatio="zoomKeep" interval="15" tags="artist" ></element>

Is anyone else able to get the Gallery tag to rotate images?

20
Questions / Re: Portable sync issues with "folder per playlist" option
« on: April 14, 2015, 12:32:14 AM »
That's good to hear.  I know he's in the middle of major architectural changes that obviously take priority, but hopefully he can take a look in one of the subsequent releases.

I guess I should have posted this in the Bug Reports section.  Should I repost it there?  Or can someone move it?

21
FLAC is absolutely compressed.  It's lossless, so it can't compress as much as lossy codecs like MP3, Vorbis, etc., but it's definitely compressed.

It'll vary depending on the nature of the music, but the FLAC file should be about 60-65% the size of the original uncompressed WAV.

My rule of thumb is you'll get about 3.3 albums per GB on average with FLAC.  Again, your mileage may vary, but averaged over 100's of albums it should be in that ballpark.

22
Questions / Portable sync issues with "folder per playlist" option
« on: April 12, 2015, 08:04:48 PM »
I've been using the portable sync features for a long time and have always found them to be excellent (the best I've seen).

Normally I sync to an <AlbumArtist>\<Album>\<FileName> structure with M3U playlists as the primary way I use my portable devices, especially in the car.  And this has worked beautifully in the past.  However, I recently got a new car and unfortunately the USB support is shockingly bad: unusable navigation and no playlist support.  So, the only workable option is to use a folder per playlist structure.

I was very happy to see MusicBee had this option, but noticed a couple significant issues after using it:

1) When using the "folder per playlist" option, the encoding doesn't respect the number of threads option.  I have the encoding threads set to 4 to utilize all my cores, and with normal synching this works as expected.  However, with the "folder per playlist" option it only encodes one file at a time.  I didn't think this was that big of a deal at first, as I only expected it to matter for the initial sync when I was loading 1000's of files.  However it exacerbates problem 2 on every subsequent sync.

2) Once you've synched the device, subsequent changes to the playlist in MusicBee can cause the entire playlist to have to be re-encoded the next time you sync.  I guess this is because the hard-coded file name format includes the playlist track sequence number.  So if you insert a track at the beginning of the playlist, all subsequent tracks get a new sequence number, which I guess causes MusicBee not to recognize that the files are already there, causing them all to be re-encoded on the next sync.  This is really a drag, especially when combined with problem 1, as it can take a very long time to re-encode long playlists.  It seems like it should be possible to recognize which files are already present on the device regardless of sequence, rename them with the correct sequence and then only encode new/changed tracks.

23
Agree with the others re FLAC over APE.  FLAC has much better tool and player support and is also open source, so it's really the only choice for relatively future-proof archiving.  Last time I checked years ago, APE did not have a proper open source license, so I wasn't comfortable using it as an archive option.   I have over 5000 CDs ripped to FLAC and obviously never wanted to repeat that exercise again.  FLAC offered the best combination of wide support and future-proof assurance due to the non-restrictive open source license.

Regarding FLAC versus high-bitrate lossy, I say use both.  I use FLAC for playback on my stereo at home but transcode to high bitrate MP3 for portable use.  MusicBee is very good at doing this via the portable device synching features and the Format Converter.

To answer the original question about how to rip, I'd recommend cueripper from the cuetools package as the best free option.  I actually use EAC, but only because I put a lot effort into customizing and automating it years ago and haven't wanted to redo it all again for another tool.  But if I was just starting, I'd go with cueripper.

24
Visualizers / Re: Milkdrop Visualiser Support
« on: September 04, 2014, 06:20:38 PM »
I think that showing "MusicBee" might have been coded into Steven's adaptation of Milkdrop.  Now knowing the folder that the variables are stored in, might allow a change to be made so that the song titles can be made to work.

Probably outside the scope of this forum, but I took a peak at the MilkDrop code and it looks like it's using window messages to get the current song info (title, length, current position, etc.) from Winamp.  So Steven would probably need to implement handlers for those message types in MusicBee.  Either that or modify these functions in MilkDrop to get the info some other way.  I don't know if MB already exposes that info in some other way that would be readily accessible from a C++ program or not.  Either way, I'm guessing it's not going to be real high on Steven's TODO list.  :)

If anyone is interested in the MilkDrop code, you can get it from http://www.geisswerks.com/milkdrop/.  Just search for "GetWinampSong" in support.cpp and you'll find the handful of functions involved (around lines 250-300).  If Steven didn't want to change MB and the current song info is available some other way, then it should just be a matter of changing these few functions.

25
Plugins / Re: Dacp Plugin: control MusicBee using iTunes-compatible apps
« on: September 03, 2014, 08:39:33 PM »
Currently using Telsos android remote exactly what additional functionality does this plugin provide?
Thanks

Mostly it gives you choice.  It let's you use any iTunes compatible remote control app, of which there are a multitude, so you're pretty much guaranteed to be able to find one you like.  Also, it currently supports more features than Kelsos' app, which is still pretty early in development.

BTW, I'm not knocking Kelsos' app.  What he's completed so far is good, but it will take a while to catch up to some of the more mature apps out there.  Where Kelsos's app may ultimately get the edge is that he may be able to deliver unique, Musicbee-specific functionality that is outside the scope of the iTunes/DACP spec.

Check out the Retune app for an example of a really good, free remote control app that works with this plugin.

26
Visualizers / Re: Milkdrop Visualiser Support
« on: September 03, 2014, 08:16:56 PM »
Hey guys. Don't have or want winamp, so could someone upload that ini file. Possibly in the future it could be included with the plug-in?
Cheers.

I understand not wanting to install unneeded software, but unless you are already familiar with the settings I think it would be really hard to jump right into the ini files.  There are a huge number of settings and the names aren't always obvious.

The Milkdrop settings UI in Winamp provides a lot of explanation, plus you can change settings in the UI and see what get's modified in the ini file to figure things out.  Also, it looks like there are video adapter GUIDs in the ini that I would assume are specific to the hardware in a given machine.  Not sure what would happen if those are missing or incorrect.  Probably best to let Winamp create a valid file first.

I would suggest installing Winamp, but just deselect most of the options during the install (disable shell integration, disable cd autoplay, don't install the agent, etc.).  Then it's really unobtrusive and shouldn't cause any problems.

27
Visualizers / Re: Milkdrop Visualiser Support
« on: September 03, 2014, 01:02:58 AM »
Is there any way to access these settings with the plugin?



I finally figured this one out.  I tried about a year ago to get Milkdrop to read the milk2.ini file from MB, but could never get it to work.  Plus Milkdrop wasn't really working with WASAPI at the time so I lost interest.  But now that it's working well in 2.4 I thought I'd give it another shot.

This time I broke out Process Monitor and was able to see where it was looking for milk2.ini:
C:\Program Files (x86)\MusicBee\Plugins\Plugins\milk2.ini

The double Plugins folder is not a typo, that's actually the path it's looking for.

So if you want to customize Milkdrop settings in MB:
- Install Winamp and configure Milkdrop as desired - this will create the milkdrop ini files
- Find Winamp's milkdrop ini files on your drive.  They should be in %APPDATA%\Winamp\Plugins\Milkdrop2.  Just search for milk2.ini if you can find the folder.
- Create the additional Plugins folder under C:\Program Files (x86)\MusicBee\Plugins
- Copy all the files from Winamp\Plugins\Milkdrop2 into the new MusicBee\Plugins\Plugins folder

At that point Milkdrop in MB will now use your custom settings.  Once you've got it setup you can just edit the ini files directly to change settings.  Or go back to Winamp to change settings through the UI and then copy the files over to MB again.

Note however that not all features are supported in MB.  A couple issues I found so far:
- Start full screen (start_fullscreen=1) doesn't work.  Use start_fullscreen=0 to start it in MB window first, then you can switch full screen.
- Showing song titles doesn't work.  This was a bummer, as it was something I really liked in Winamp.  You can enable the feature, but it always just shows "MusicBee" for the title.  No idea how Milkdrop gets this info from Winamp, so no idea if it would be hard to fix or not.

But a few nitpicks aside, it works.

28
Makes sense.  Thanks.

29
Thanks, Steven.  So at least I'm not crazy. :)

It would be nice in a future release if the volume analysis could always be done on new files, regardless of whether or not the inbox is used or how the files are added to the library (startup, continuous, manual, etc.).

I'll try using the inbox in the meantime.

Thanks again.

BTW - 2.4 is a really impressive release.  The UI enhancements and other changes are fantastic.

30
Thanks for checking that out.  I guess the good news is that MB should do exactly what I want, but I'm not sure what might be keeping it from working in my setup.

How are you adding the new files to MB?  I'm using "rescan at startup" and I've also tried manually rescanning, with the same result in both cases.  New files are recognized and added, but no volume analysis.

Is there any visual indication in the UI when the volume analysis happens on the new files?

When the new files appear in MB has the volume analysis already happened, or is there some delay after the files show up before the volume analysis is triggered?

Can you think of any other setting besides "calculate and write missing replay gain tags for new music files" that could affect this?

Again, thanks for the help.

Pages: 1 23