Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Samson]

Hi All,
(MC 18.0.211)
I am doing a "handheld sync"-and-convert to MP3 with transfer of music files to a USB Flash drive to use in my car (which has a usb connection and MP3 player).

All is great but the problem is for some albums the track names [Name] are listed as track number- artist's name-name of song eg 01-Angus and Julia Stone-Lonely hands. On the car display the actual track name gets cut off due to lack of screen space. Presumably it is getting this naming configuration from parsing the filename path to the hard disc where some of the albums are indeed named this way.

Historically, when importing into MC I changed the [Name] field to just the actual track name eg "Lonely Hands" in above example. So within MC all is good.

Is there any way to force the conversion/transfer of music to follow the library field values rather than filepath names?.
I tried using update tags from library but doesnt change the name of the music file on the hard disc. Adding [Artist]\[Album]\[Name\ to the handheld options "audio Path" creates an additional directory with the track name but the track inside is still incorrectly named. Do I have to use the Rename tool to change the filename to be inline with the library field [Name]?

Thanks for any advice.
David

[MrC]

Rename after sync is the only way unfortunately.

[Samson]

Thanks MrC,

you mean manually rename the files on the usb flash?

what about using the file rename tool to change the names of files on HDD and then re-sync or do fresh sync. I'm not sure this would be less effort ??

Thanks again

[MrC]

Use whatever method suits your needs the best.  You could:

   - sync, and use another tool to do the rename
   - sync and then import the sync'd HH items into MC and use the rename tool
   - rename the files first in MC and then sync.

Its cumbersome to be sure.

[Samson]

Thanks MrC

[Samson]

Trying to sort the above I noticed that inside every HDD folder has been placed an MP3 file sitting alongside of the FLAC file ! It is named "[Name] - cache audio custom" . At first I thought it was a  small sync file required by JR database but they are around 10mb in size and is playable. This would massively use up disc space for no reason ! What am I missing or did I do wrong ?

[MrC]

Disable the cache in the options if you don't need or want it.

[Samson]

lol, yes I am learning 'on the fly' .

In the thread referred below you mention, "I tend to use virtual handheld syncing to maintain a lossy copy.  It does require manual initiation of the sync, and it can occasionally hiccup when certain tags change (causing a copy of a lossy item instead of replacing it).  But I've found these niggles to be easier to manage than stacks.  Others find the opposite.  Experiment to see which suits your work style."

So I have learnt that MC can create a custom folder where duplicates can reside and presumably I can create this and transfer my cached duplicates there instead of cluttering my other folders.Tag changes should be sync'ed this way.Is that what you meant by a virtual handheld syncing?

Thanks

_______________________________________________________________________________ _____________________________
For others stumbling across this thread there is more about the duplicate issue here http://yabb.jriver.com/interact/index.php?topic=81369.0
and Vincent Kars wrote a great general tutorial here http://www.thewelltemperedcomputer.com/SW/Players/MC14/MC_sync.htm

[MrC]

Yes, handheld sync is essential a Convert to a device driven by a preselected set of files, where items converted are remembered for the next occasion when convert may happen.  This list is used to minimize convert time, and to allow for keeping both sets consistent.  A virtual HH sync is essentially the same, but instead of to a device, the sync's target is a folder.

I worked through many bugs with Matt last year, and all but one are resolved (the occasional duplicate file after tag change), so I find it fairly reliable now.

[Samson]

Thanks MrC. The thing that threw me was that 3rd party syncing programs copy and sync without creating duplicates on the host side.It seems duplication occurs in MC if you additionally do a conversion (transcode) say from FLAC to MP3 . Presumably this is so any future tag changes to FLAC fies will be passed on to the corresponding MP3 duplicate (virtual sync) and eventually synce'd to the MP3 on the (real) HH/usb flash drive.

[MrC]

Because MC can:

  - Stream via DLNA
  - Convert
  - Sync to HH

it uses a conversion cache by default, so that users don't have to await the time it takes to transcode the same item each time.

But the implementation is simplistic - it provides only one conversion form, and each of the above may want different, say, different bit rates.  So many of us just disable the cache, and pre-compute our own as needed for external devices.

[MrC]

By the way, one of the items on my Wish List:

Convert Format:  Support more flexible Base path, Folder rule, Filename rule
The Convert Format tool uses Convert to this directory (which is tantamount to a Base path), and uses a rigid "And create # levels of directory structure".   It would be very useful (and probably clearer, more consistent) to replace that mechanism with the standard Base path, Folder and Filename rules.

[Samson]

Understand now and thank you for your patience.

Maybe the additional/revised features can be added in MC19....sure would be nice to use the MC field values in the namimg of synced files

Cheers and thanks again
David

[Samson]

For others stumbling across this thread the naming problem was dealt with using a combination of  Tools > "Library Tools".

Most of my imports had the correct [Name] inside MC as this was done at time of import. They had the wrong "Filename (name)" ie the last thing written at the end of the file path in explorer. using tools > Library tools > Rename,Move , Copy > select only "Filename" and set "rule" as [Track #] - [Name] did the trick, renaming the files as they should have been in the first place 01 Name of Track One, 02 Name of Track two...etc. Aftere a few trials I got braver and started to do it in larger batches.

For the files that had the wrong naming structure inside AND outside MC, eg 01 - (name of artist) - name of track, I used the "Find and replace tool" , replacing "(name of artist)" with blank ie leave blank so the result becomes 01 - name of track. Warning, this will delete exactly what you type and in my case the name of artist in the filename was enclosed in () or [] so was fine.If you also have the name of the artist specified in the directory structure of the file path (as opposed to just the filename) it is a problem.Now what I did was inside MC select the [Name] fields of these files and delete, leaving them blank. Next, Libray Tools > Fill Properties from Filename.... Done.

[MrC]

Sounds like you're making progress.

Find and Replace may not be necessary for what you're doing.  If you use a Rename rule that defines the file path and file name structure, just a Rename will be sufficient.  That takes the manual work out of the process.

[Samson]

Hi MrC,
In my case the Base path (directory structure) was ok up until the last bit ie the filename(name) was the only wrong part. Providing in those instances I had the correct [Name] field within MC,I was able to fix with one operation using the Filename checkbox in "Rename,Move & Copy Tool.

Some cases I had both the wrong [Name] field within MC and the wrong Filename(name) in the directory structure.That required two operations.

Just to clarify for others, MC has two "Find & Replace" Tools. One under Library Tools directly and another as a subset of the "Rename,Copy,Move" Tool. I used the latter.The former has more options but appears only to operate on MC fields not on the file structure.

[Samson]

Hi MrC, if read this I wonder if you might be so kind to take a look http://yabb.jriver.com/interact/index.php?topic=82719.0 .Not sure is a bug or something I,m doing wrong.Thanks and cheers

[MrC]

Replied.