Print

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

[vagskal]

I want to convert flac files to mp3 files located on another disc. The flac files in MC have no embedded cover art (since this would be against the flac standard), but cover art in a folder.jpg file in each folder for one album. The cover art shows up just fine in MC, but it is not converted with the mp3 files and the folder.jpg is not transferred to the new location for the mp3 files (I have set the folder depth for the converted files to 2, which gives the same folder structure as the flac files have).

Is there a way to have the cover art embedded in the mp3 files during conversion or to get at least the folder.jpg copied to the folders with the converted mp3 files (provided that the folder structure is the same as for the original files)?

I also looked for a way to set the file path for the converted files using MC library fields, but found no such option. Have I overlooked something?

[Lasse_Lus]

set up a (local) handheld device

[vagskal]

set up a (local) handheld device

Aha, now I understand. Thanks!

It was the handheld bit that made me never consider that option for conversion to another local drive (and when I searched the forums I found this http://yabb.jriver.com/interact/index.php?topic=55601.0, but did not understand where the cover art option was). The handheld sync will give plenty of options.

One option is to set the audio path. Do you or anybody else know if it is possible to set also the file name bit with this (or any other) option or to just retain the original file name (with .mp3 instead of .flac, of course)? The reason for this is that I have some deluxe edition remastered CDs with two discs containing mono and stereo versions (or similar) and MC reports files on those CDs as duplicates since it seems to ignore the disc number and the original filename.

[Lasse_Lus]

i don't think you can set the filename (as a part of a handheld profile) you will get the original filename+extension, you maybe can import those converted to a temporary d'base and make your chnages there ?

[vagskal]

i don't think you can set the filename (as a part of a handheld profile) you will get the original filename+extension, you maybe can import those converted to a temporary d'base and make your chnages there ?

Thanks again!

OK, the original file name would be fine since it is in the format [Disc][Track #]. But how do I get MC to not consider files with different file names as duplicates? I assume that what MC marks as a duplicate will not be converted.

[Lasse_Lus]

actually i think mc sets an (1).file when dealing with dups, but maybe not here..

just popping ideas, but what about you set up 2 local handelds then drags those folders into an temporary MC database and make your changes..

test test test  you can always delete and  redo

..or do the changes directly under handhelds - > details have a look 

[vagskal]

OK, thanks! Will test (but with 15k files to convert it will take a while, hence my curiosity to find out as much as possible beforehand).

[Lasse_Lus]

then you have the cache stack option, maybe that is for you..i love stacks but i have not used the cache so i leave it here 

[vagskal]

then you have the cache stack option, maybe that is for you..i love stacks but i have not used the cache so i leave it here 

Thanks for the tip. I guess cache stacks might be useful, but I am afraid that I did not understand what that was (how/when it is useful?) and therefore I did not check that option. I am afraid that the wiki entry on this is also incomprehensible to me (I simply do not get the point):

Stacks as Cache
Currently only available for the handheld conversions. When enabled under MC's Handheld options (select Cache converted file (via a stack) under Options->Handheld->Conversion->Conversion Cache), MC does several things.

If MC needs to convert a file, the files stack is searched for a file of the requested type. (MP3, WMA, etc.)

If the file is found under the stack location, it is used. Otherwise MC uses any available stack file of the appropriate type.

If no stack file is available, MC searches for the file where the conversion engine would put it. If found there, it is used and stacked with the original file (unless, of course, it already is in a stack).

If not found there, MC will convert the file, copy it to the stack location directory, and stack it with the original file.

As you might have figured out by now this is the first time I am using the handheld or conversion features of MC (my iPod Touch will not sync with MC...). I have so far experienced more crashes in the process (4-5 of MC and 1 of lame.exe) than I would expect from a commercial software. I have also discovered that the tag mapping is not as good as when ripping to both flac and mp3 using dBpoweramp (or using its batch converter). That was to be expected since MC currently does not support all standard mp3 ID3v2.3 tags and de facto standard flac Vorbis comments, but it means that I will later have to use an external tag editor with scripting abilities to adjust a lot of pretty standard tags (such as albumartist/band, discnumber/TPOS, Organization/TPUB) in the converted mp3 files (I hope this will not result in a resync where my edits of the mp3 files are wiped out...). The big advantage of MC is that it can actually sync the flac and mp3 libraries (I hope) so that when I change the tags in a flac file it will also be reflected in the tags of its mp3 sibling (at least after performing the aforementioned scripted adjustment with an external tag editor).

Once again thanks for your help! I would never have thought of the "handheld" sync otherwise.

[MrC]

Without trying to be negative, test out some files first in your HH conversion.  Currently, there are issues with HH cache conversion, ignoring the cache (and re-converting always), and time it takes to re-create the sync list on almost any operation you do.  The process is cumbersome, and does yet work the way it could.  Hopefully this will get addressed soon.

[Alex B]

I use the "virtual" handheld option without stacking the converted files, i.e. I have a repository of synced MP3 files and playlists in a hard drive location. From there I burn MP3 CD-RWs for car and sync various portables (phones, flash memory cards, etc).

Recently I have used MC15 for the conversions from my main library and MC14 for maintaining a separate small library of the converted files and playlists. MC14 imports the newly converted files automatically and it is easy to do further tasks like burning and syncing actual HW devices from the full MC14 interface.

I have never bothered to convert my complete lossless archive. I just add something new from time to time.

[vagskal]

I just wanted to report that all went well (apart from all the crashes and MC thinking files with different filenames are duplicates and will not convert them). But it took a while. The album gain tags in the flac files, which I had imported to custom MC fields, were not converted so I had to also use an external tool to re-apply gain, which is a time consuming task when you have a lot of files. I wish MC would as an option support converting the actual album gain tags in the existing files (even though MC does not use them), at least if the user has imported them into custom fields (why exclude just those fields from conversion?). MC also created a playlist folder in the destination which I did not want and I could not find an option to prevent this. Furthermore, MC created a hidden Database.mpl file in the destination, which I do not know the purpose of (at least it does not seem to speed up resync which, as MrC pointed out, is not particularly fast).

But I am happy. Applying the necessary tagging script and gain tags to the mp3 files with external tools did not trigger a re-sync (so it seems to be not an actual - two way - sync operation, which suits me fine). A change of the tags in the flac files, however, did trigger a re-sync of just those files, which was exactly what I wanted. I just have to remember to apply (album) gain to the whole album if only some files in an album are changed and to apply the necessary tagging script to just the changed files (the script does not work for the unchanged files which have already been through the script). The cover art converted nicely (embedded in each mp3 file and a folder.jpg on top of that in each album folder) as well as all custom MC fields _except_ the album gains tags I had imported (strange). It worked using expressions for the file path.

Thanks for the input!

(I was curious, though, why Alex prefer to use two different versions of MC. I did keep a copy of MC 14 when JRiver said that MC 15 was in beta but after that I think I uninstalled MC 14 since I could not see any difference in the features for audio files that I use for tagging, organising and searching my music; I do not use MC for ripping or playback or as a music server or the cover art or theatre views, or for anything but audio files. After the introduction of MC 15 final, improvements to the features I use have come gradually - locked views (great!) and some improvement in the speed of the tag editing action window (but I would need more when having a lot of files displayed at once), and Matt has a 40% speed up of a complicated view waiting for me in the next MC build..., and you, Alex, said that someone at JRiver is actually working on improving the audio file tagging support (promising!).)