Print

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

[Matt]

We recently changed how CUE files are handled so that we can nicely handle CUE files that point to multiple files.

This had the unfortunate side effect that CUE files will be reimported, because the filename changed.

After reimport, new files will have a ;1, ;2, etc. after the filename.  The old files without the trailing number should be removed. 

Just search for "cue" and remove the files from the library.  Then run the import again on your CUE directory.

Sorry for any trouble this causes.

[ssands]

We recently changed how CUE files are handled so that we can nicely handle CUE files that point to multiple files.

This had the unfortunate side effect that CUE files will be reimported, because the filename changed.

After reimport, new files will have a ;1, ;2, etc. after the filename.  The old files without the trailing number should be removed. 

Just search for "cue" and remove the files from the library.  Then run the import again on your CUE directory.

Sorry for any trouble this causes.

Hi, can you please elaborate (for those of us who aren't as well-versed in cue file usage and management)? Or point to a good resource?

How did the filename change? Does MC actually rename a filename?
What filename are you writing about? song filenames? cue files?
What does the ;1, etc. denote and why should the old files be removed?
Are you saying we should manually remove all *.cue files?

There is a lot not clear to me, and the wiki entry for cue files doesn't really help. As I mentioned, if there is a recommended link that would be quite helpful.

[Matt]

How did the filename change? Does MC actually rename a filename?

We don't rename the file.  It's just that the filename we keep in the database has changed.

It used to be:
C:\1.cue
C:\1.cue
C:\1.cue

And now it's:
C:\1.cue;1
C:\1.cue;2
C:\1.cue;3

What does the ;1, etc. denote and why should the old files be removed?

It's the track number and the counter is necessary so each entry has a new filename.

Are you saying we should manually remove all *.cue files?

Yes, if they don't have the number at the end of the filename.

[6233638]

We don't rename the file.  It's just that the filename we keep in the database has changed.

It used to be:
C:\1.cue
C:\1.cue
C:\1.cue

And now it's:
C:\1.cue;1
C:\1.cue;2
C:\1.cue;3

I don't have any file in my library that was ".cue" they imported with ".flac" previously, and now ".flac;1" etc.
 
While people will certainly want the new cue file handling for new imports, I think anyone that has been using MC until now will want to use their previous files which are properly tagged, while the new cue imports are likely not. Easier to remove the new duplicates than disrupt a working system.

[Matt]

While people will certainly want the new cue file handling for new imports, I think anyone that has been using MC until now will want to use their previous files which are properly tagged, while the new cue imports are likely not. Easier to remove the new duplicates than disrupt a working system.

Please remove the old entries.  Keeping them will lead to trouble.

[MikeO]

Hi what is happening with CUE files , I upgraded to build 37 this morning now my library has literally thousands of empty entries.

I have folders where the CUE text file still exists but the individual files have been split out using CUE Tools etc. It was the way I preferred it at one stage.

Where I have this when I select an album and look at files , I have the split out files and a whole set of blanks , no <Name. no <File Path> just blank entries.

Now what do I do , if I play the album I get music , blank , music and so on

My whole library is trashed or so it seems . There looks like a lot of work to put it back straight.

What do I delete the Text CUE files or what , I am nervous not to delete the wrong thing.

Mike

[JimH]

Please read the thread, starting at the top.  You should find what you need there.

[MikeO]

I am still not clear , I have a duplicate of virtually every file in my library with no Name field and no Path field , just blank. in File View I see about 120k files which is around double what is actually there./

JRemote shows almost any album with Track1, a blank line , track2 , blank line etc.

Are you suggesting that I physically remove all *.CUE files form my Hard Drive and re run auto import ?

The above does not fit what I see. I have an example folder with no CUE file , but it too has been duplicated with no Name or Path.

They are easy to sort out and delete BUT where did they come from. The Date Imported is this morning shortly after I upgraded.

I think maybe some detailed step by step guide as to how to sort out the mess. At the moment my library is a complete mess of empty entries.

Is this the same issue or am I missing something ??

Mike

[JimH]

Try Matt's instructions.

[6233638]

Are you suggesting that I physically remove all *.CUE files form my Hard Drive and re run auto import ?

Removing the cue files from your drive won't do anything once they have been imported.
Matt's suggestion was not applicable to my library, since I don't have a single .cue file listed in my library, it's all .flac;1 or similar.
 
I just did a test, and while it's not mentioned in the changelogs, it seems that cue files which have been removed are no longer being re-imported every time auto-import runs.
 
So you have a number of options:
 

1.  Filter out the newly imported cue files using a smartlist, and then delete them. As of build 37, it seems like this will now work.


2.  Restore a previous library backup before the cue files were imported, and disable cue files in your auto-import config.
This will prevent you using cue files in the future though, since everything would be re-imported again if you were to re-enable the option.
 
There should be a checkbox when restoring a backup to disable auto-import temporarily, so that you can adjust the auto-import config before it runs again and re-imports all your cue files.


3.  Delete the cue files from your drive, and restore a previous backup prior to the cue files being imported. Now the duplicates are gone and the cue files no longer exist.


4.  Put up with the disruption to your library, use the cue files instead of the tracks, and delete your original files, discarding any and all changes you have made to them. (ratings, date imported, updated tags etc.) This is the JRiver recommended method.

The above does not fit what I see. I have an example folder with no CUE file , but it too has been duplicated with no Name or Path.

Do your tracks have embedded cue files?

[MikeO]

Hi

Yes I see what you're doing , for now I have reverted to an old version and restored a BU but I think I still have  some xxxxx;2 type files.

I do have some folders with split tracks and a text CUE file and some with even the Big CUE file so I must have some CUE or APE file which are a whole album those obviously I shouldn't delete

From Matt's comment its the OLD files we need to delete not the newly created ones , its sounds like the new way is with thee semi colon; number format

Matt please confirm

I think we need Matt to give us the definitive way of clearing the mess. I think I am going to lose any enormous amount of "Tag Maintenance" by this .

I seem to have done nothing else all week but sort out my Library( Wifey quote !!). Good job I'm retired !!

A bit of warning of the fall out from this may have helped

Isn't everybody having this grief , it only seems like a few commenting


Cheers

Mike

[bp-plickner]

I went crazy all day yesterday sorting out my libray. I stumbled on the link referenced in solution 1

1.  Filter out the newly imported cue files using a smartlist, and then delete them. As of build 37, it seems like this will now work.

My library is now back to normal. I also unchecked the cue file option in auto import.

Thank You!

[6233638]

Isn't everybody having this grief , it only seems like a few commenting

I think it depends on a lot of factors.

I haven't ripped anything as FLAC+CUE for a long time, it's only my very oldest rips when that was the only way to get gapless playback which are like that. And most of those have since been split into individual files.
I suspect most people won't have been ripping to FLAC+CUE for a long time either. Most apps rip to individual tracks by default.
 
Only certain types of cue file are affected, I believe, not all of them.
 
Not everyone is always up to date right away, and not everyone visits the forums.
 
 
I agree that features like this which are potentially going to make very destructive changes to the library should have safeguards in place to undo their changes.
 

I went crazy all day yesterday sorting out my libray. I stumbled on the link referenced in solution 1
My library is now back to normal. I also unchecked the cue file option in auto import.
Thank You!

You're welcome. I'm glad that helped.

[Matt]

I think we need Matt to give us the definitive way of clearing the mess.

Pick all your old CUE files and remove them from the library.  Then import the CUE files again.

Structurally you want to remove any entry that doesn't have a semi-colon and number in the filename.  The new entries all will have the semi-colon and number.

[ssands]

Chiming in here again...

I have spent far too much time cleaning up my library this week, after spending a lot of time getting it to the state I wanted it in. I reverted MC back a few versions and restored an old lib backup. Then had to go through the whole lib to clean it up and kept finding really weird issues, some even related to cover art that would not "stick", despite being in my library. (Finally, had to grab an image from the internet and use that instead).

I think for Jim and Matt the instructions and situation are very obvious and clear, but it is not necessarily for those of us who are not intimately involved with the inner workings of MC and how it might handle all the variations in files.

I don't believe the Matt's instructions have covered the situation of .cue files + individual tracks. Or maybe they have - I don't really know.

Plus, I am fairly sure that once I do upgrade to the next stable version, my library will be hosed again, because of these cue files and how they are handled.

Also, please consider that if someone keeps asking the question, then the previous response was likely not clear to them (even though it might be extremely clear to the person providing the answer). Often times, the answer needs to be rephrased or made more explicit.

Thank you.

[Fangio]

Well, I have spent several days sorting out my library. I had many FLAC+CUE files which I have now split and re-imported, losing all of my personalised tagging in the process, of course. I now have now removed all CUE files from my library.

Could I politely request that next time you implement such a destructive improvement, you give us prior warning?

There should be a checkbox when restoring a backup to disable auto-import temporarily, so that you can adjust the auto-import config before it runs again and re-imports all your cue files.

+1

[MikeO]

Thanks everyone , It seems I have a way forward but at what cost , if I follow Matt's way I will lose all the personalised tagging I have worked so hard to create and maintain.

If I delete the newly created xxx;2 files etc with a Smartlist , as per 6622638 then I lose the ability to use CUE files ever again, if I reactivate CUE files in Auto Import it will happen all over again I assume.

Its the proverbial rock and a hard place , I suppose I bite the bullet and re do the tagging JUST to stay standard and to avoid any addition issues going forward, and to maintain the ability to use single file CUE Files.

My vote is this change was not a smart one , no matter how good the new feature is , it certainly seems to have created a lot of work for me. Ultimately I suspect that I will split all my CUES and get around it that way.

I suspect using single file CUEs is not common or the outcry would have been a lot more vigorous. What is seen as best practice , a single file or a split file into tracks. MC manages the gapless playback fine so either works for me. But a lot of my music came in as single files and it saves effort to keep it that way.

Mike

[Sesam]

Just search for "cue" and remove the files from the library.  Then run the import again on your CUE directory.

I don't get this, if I remove them everything will only look fine until the next import. Sure I can disable importing cue files, but is that how we are supposed to handle this?

[6233638]

If I delete the newly created xxx;2 files etc with a Smartlist , as per 6622638 then I lose the ability to use CUE files ever again, if I reactivate CUE files in Auto Import it will happen all over again I assume.

If you simply remove the newly imported cue files (file.ext;1) they don't appear to be getting re-imported any more.

This means that you can continue to have cue files enabled in auto-import, and only new cue files should be imported from now on, rather than re-importing all your existing cue files.
 

I don't get this, if I remove them everything will only look fine until the next import. Sure I can disable importing cue files, but is that how we are supposed to handle this?

Build 37 seems to have fixed the issue with the cue files being re-imported after removal from the library now.

[Sesam]

If you simply remove the newly imported cue files (file.ext;1) they don't appear to be getting re-imported any more.

This means that you can continue to have cue files enabled in auto-import, and only new cue files should be imported from now on, rather than re-importing all your existing cue files.
 Build 37 seems to have fixed the issue with the cue files being re-imported after removal from the library now.

This doesn't work for me, I have updated to version 20.0.37, deleted the cue files. And then when I import the duplicates re-appear.

[6233638]

This doesn't work for me, I have updated to version 20.0.37, deleted the cue files. And then when I import the duplicates re-appear.

Strange. That was happening for me in build 35, but in build 37 once they're removed they stay gone.
 
It wasn't on the changelist though, so I'm not sure why that is.

[lawe]

I really think there should be an option to use oldschool import handling. I´ve got a library of maybe 3000 albums of which maybe 1000 - 1500 now have double entries.
The Album covers Genre and Year and even name of the Album (I hate the Japanese Edition YOI21345 album number etc) have been fixed for maybe a third of the albums.
If I would start to manually fix this I think it take about a month.

I sure could mount the drive and run a Ren x:\Music\*.cue *.ufo but that would´t be a good solution.

I split flac files with Medieval Cue splitter.

[kstuart]

If I would start to manually fix this I think it take about a month.

I sure could mount the drive and run a Ren x:\Music\*.cue *.ufo but that would´t be a good solution.

When I first switched to JRiver MC, I had to do that rename.

The cue file support was broken for years.  There are a number of threads in each version's Forum asking for the sort of rewrite that was finally done recently.

[Pho3NiX]

Hi I am affected by this issue, however I could not follow Matt fix.
Step "search for cue" does not work.

I have duplicate of the form

track1.flac
track1.flac;1
track2.flac
track2.flac;2
track3.flac
track3.flac;3


on about a hundred of album.
And those duplicate are not flagged by keyword "cue".


To explain a bit better the situation, the cue where not there to actively split a large image into tracks.
They where there for archival purpose, the same way I keep the extraction log.
In some other case they used to split an image file, but the image has been splitted into track using your format conversion tool.

Is there a way i can clean those duplicate ?

[Otello]

I worked for weeks writing my tags; thank you very much for destroing my library. 

[JimH]

Reload a backup.  MC makes them automatically.  File/Library/Restore.

[Otello]

Reload a backup.  MC makes them automatically.  File/Library/Restore.

Of Course:
downgraded to 20.0.27, restored the library and disabled automatic update.

Please understand that manually retagging hundreds of flac+cue files is not an option.

[JimH]

Re-read the first post carefully.  You should be able to correct the problem.

[Otello]

Yessir, I did read very carefully and while English is not my mother Language I understood perfectly the instructions in the first post.
The problem is not cancelling the old files, but that this way I'd have to edit again the tags of the new files.

[JimH]

I don't think so.

[Otello]

Unfortunately you are wrong. 

[StFeder]

Unfortunately you are wrong.  

You're right, I also tried to reimport my CUE-Files. But all tagging infos are lost then; even using "Update Tags (from Library)" before deleting the old CUE Files doesn't help. But I thought this is as it should work?! Wasn't Matt stating somewhere that all the Tag-Infos will be lost if they are not stored in the CUE-File itself? Or did i miss a chance to have MC write/correct CUE Files? That would of course do the trick!

edit 2014/24/11:
I found Matts statement. He was replying to Hoyt's reply:

I understand that will fix the issue.  See my point about MC20.31 invalidating my library that worked previously.  I don't think a proper solution is to redo everything.  I think a proper solution is for MC to honor the existing library first, then worry about other functions, like the way cue files are managed.  That should not trump existing libraries.

With this:

I'm sorry for the inconvenience.  If it's any consolation, it's a one-time thing.

For me this sounds as if everything has to be tagged again. But only once Luck is on my side: I only have to redo Name and Artist for 1000 files Every file has a different artists because those files are part of Non-Stop Mixes. Sadly nothing is stored in the CUEs

[pluto7]

I have just run a windows search of all my cue files 14,579 of them and you think it is feasable to check which ones are being reimported and to save the ones that are needed for image files and many more circumstances that mc will not support. I cannot believe that I am alone having this problem. I do have more thing to do than to restore my mc system disruption " even if possible" created by an update.

[Sesam]

For now I disabled importing of cue files completely, it was the only way for me to get rid of the duplicates. As I have all my albums stored as separate FLAC files and a cue file for archival purposes. I would have hoped that the cue file would basically be ignored if you had separate FLAC's containing embedded tags.

But the more I'm reading this thread, the more confused I get. Am I understanding this correctly, that Media Center will now put priority in reading tags from the Cue instead of the embedded tags in FLAC?. Will it even make changes to the cue files, if you edit some tags in MC? (I hope not, as I want the cue files to stay original for archival purposes. As I often use custom more personalized genres etc.. in the tags embedded in FLAC's).

[Matt]

Just to state the instructions one more time:

Delete any CUE files from your library.  Then reimport. The new files will have a semicolon and number in the filename.

You'll have to reset the tags if you've customized your CUE files.  I'm sorry.

[Otello]

Quote from: 6233638 on November 11, 2014, 09:05:50 am

While people will certainly want the new cue file handling for new imports, I think anyone that has been using MC until now will want to use their previous files which are properly tagged, while the new cue imports are likely not. Easier to remove the new duplicates than disrupt a working system.

Please remove the old entries.  Keeping them will lead to trouble.

Dear Matt,
can you please be more specific about the troubles involved with keeping the old files and deleting the new ones?
On my side, following your instructions I'd lost my custom tags for hundreds of disks, but I have a life : I will not re-tag.
Deleting the new files, (after isolating them in a smartlist, as suggested by 6233638), could be an acceptable solutions, if the troubles involved are not so serious; anyway it's a better solution than stopping updating JRiver.

[Matt]

Dear Matt,
can you please be more specific about the troubles involved with keeping the old files and deleting the new ones?
On my side, following your instructions I'd lost my custom tags for hundreds of disks, but I have a life : I will not re-tag.
Deleting the new files, (after isolating them in a smartlist, as suggested by 6233638), could be an acceptable solutions, if the troubles involved are not so serious; anyway it's a better solution than stopping updating JRiver.

You want to delete the old records.  It's important that the new records be the ones in the library or else you'll have all sorts of trouble.

[Sesam]

Just to state the instructions one more time:

Delete any CUE files from your library.  Then reimport. The new files will have a semicolon and number in the filename.

You'll have to reset the tags if you've customized your CUE files.  I'm sorry.

Hmm, I have deleted the cue files (using the smartlist as suggested above), and then re-imported. But the duplicates are still re-appearing, currently running MC 20.0.41.

One curious thing is that even though I have approx 500 albums with cue files, the duplicates only appear for 14 of the albums. Could this be some kind of bug, because why does this keep happening with just those albums?.

[kstuart]

Here is what is needed:

The ability to save tags (file properties) for CUE files and single-FLAC file combinations to a SIDECAR file.

Then the user can re-import using the new corrected CUE file support.

Then the user can move the tags (file properties) from the SIDECAR file into JRiver MC20.

If someone at JRiver can spend a little time creating a utility to do this, it would save thousands of hours for JRiver customers in total (not an exaggeration - note the number of threads on this, and remember only 10% of people post about problems they have).

[ssands]

Here is what is needed:

The ability to save tags (file properties) for CUE files and single-FLAC file combinations to a SIDECAR file.

Then the user can re-import using the new corrected CUE file support.

Then the user can move the tags (file properties) from the SIDECAR file into JRiver MC20.

If someone at JRiver can spend a little time creating a utility to do this, it would save thousands of hours for JRiver customers in total (not an exaggeration - note the number of threads on this, and remember only 10% of people post about problems they have).

This seems like a good solution, but I would like to add a comment:

This was a breaking change. It seems like it was probably made for a really good reason, but to implement it without a way to migrate, preserve users work, and maintain library integrity was not a good user experience, by any means.

I have not seen the problem or the intended solution documented very well. I see 4 use cases, and I don't know what the intent of the latest fix has been on these four:
UC1: One large flac file w/a cue file indexing the tracks contained inside the large cue file
UC2: More than one large flac file (e.g., one for each side of a vinyl rip) with a single cue file indexing the tracks contained inside the files.
UC3: One large Flac file + indiv. song flacs + the cue file that indexes the large flac file
UC4: Indiv song flacs + a cue file.

I suppose there is another permutation or two lurking there, but I think the idea is clear. I have seen all the above Use Cases discussed and actually think they all apply to me, but I haven't seen an explanation of what the latest fix is meant to address.

A solid, detailed entry in the wiki is likely warranted for this. There are many threads with information scattered about. Recently there was a request for quick hits (or something like that). I think this is a solid contender. I would certainly roll back MC, restore a library backup and then upgrade to the latest build if I knew:
1) the migration was handled properly, and
2) there was a clear explanation as to how the change impacted the above scenarios so I knew what I might need to do going forward.

Thanks.

[JimH]

I have not seen the problem or the intended solution documented very well. I see 4 use cases, and I don't know what the intent of the latest fix has been on these four:
UC1: One large flac file w/a cue file indexing the tracks contained inside the large cue file
UC2: More than one large flac file (e.g., one for each side of a vinyl rip) with a single cue file indexing the tracks contained inside the files.
UC3: One large Flac file + indiv. song flacs + the cue file that indexes the large flac file
UC4: Indiv song flacs + a cue file.

I think that list itself is a good argument against using CUE files at all.

Matt described what to do in the first post.  At least some of the confusion is coming from people who don't want to do what he suggested there.

[ssands]

I think that list itself is a good argument against using CUE files at all.

Matt described what to do in the first post.  At least some of the confusion is coming from people who don't want to do what he suggested there.

Jim, respectfully, I disagree. People don't want to lose the time they spent on organizing their libraries. That's why I think KStuarts suggestion is a really good one.

And what you assume is people not wanting to follow Matt's advice, can also be attributed, in some cases, to not understanding how the change impacts the use cases I listed above.

[Sanlitun]

Just search for "cue" and remove the files from the library.  Then run the import again on your CUE directory.

I did this but the search only returned about 6 results. I think I have close to a hundred albums showing duplicates, and not all of them have cue files in their folders.

Is there any way to turn back everything to as it was before the update and then wait it out for a fix?

Thanks!

[ssands]

Matt described what to do in the first post.  At least some of the confusion is coming from people who don't want to do what he suggested there.

I have gone back and carefully followed Matt's instructions mentioned in the first post. Again.

It doesn't work. And I think its pretty clear it is not working for a lot of other people.

cue files are removed. Directory is reimported. I don't have any cue files with a ;1, etc.

I still have duplicate entries of songs.

I (and many others) would appreciate clarity and a fix.

Again, Matt's instructions may work for one of the use cases I mentioned above, but it is not working for a lot of people and causing a lot of thrash.  Whether one thinks the existence of those use cases are an argument for the elimination of cue files is besides the point. Your customers have them and it is causing problems.

The guidance so far has not worked for a lot of people as evidenced by the number of threads and comments since the change.

[JimH]

Is there any way to turn back everything to as it was before the update and then wait it out for a fix?

File > Library > Restore.  MC makes automatic backups.

[MikeO]

Hi

My 2 penneth

In my library the main problem lies where there is an album folder with individual track flac files AND a CUE file (realistically redundant, I understand from EAC ?) , then I get duplicates. It would seem a big flac file and Cue index file doesn't cause trouble , although I have been too busy to dig that deep yet.

Matt's comment was to remove the old files and leave the xxx;1 etc files as the new format or the old ones will cause trouble going forward.

Following 6233638 advice (and script) using a smart list isolates the new ones for easy deletion (I believe ?) and leaves the old ones so that doesn't strictly follow Matt's requirements

So I have laboriously done the following

Go to each folder on the HDD and remove any CUE , TXT or Accurip files , or any other extraneous files.
Leaving Just the individual track flac files and a jpeg Folder file

Then in MC find the album and sort by [Date Imported] ASC . This gives the new xxx;1, xxx;2 files separated out at the bottom . I then delete the older duplicate flac files JUST from the library , i.e. the top option on the delete dialogue.

Now when I run Auto Import it looks like the duplicates are fixed.

I may add in a library of my size this is an absolute pain in the ...

Also as the sting in the tail , any customisation or corrections to tags are lost , so for example if a album is originally DG in German , then the Symphonien comes back and I lose my previous correction to Symphony etc . The trouble of tagging filkes to make the library look pretty is no small undertaking

Without exaggeration I must have spent 24 hours at the keyboard fixing this in the last few weeks, I am not amused.

Ultimately I am going to follow Arindelle's advice in "Why CUE Anyway?" today and split all my Big Flac & CUE into tracks and get rid of the cue files altogether -- yet more work ...

I am just a mug who misunderstands or is there a more automatic way to achieve what I been doing manually.

To add insult to injury , my Library is on my Media PC connected by Wi Fi around the house. If I make corrections on my main computer remotely on a "linked" library and then sync with the main library the changes are not made -- I found out the hard way as ever..... For example deleting files remotely does not reflect after syncing in the main library, some Tag changes do but not all . I am confused as to why ....

So I have to sit at the Media PC and make the corrections directly. Any ideas on this one ??


Mike

[kstuart]

I think that list itself is a good argument against using CUE files at all.

That's like a technical support rep saying:

" I think that is a good argument against using Windows.  Buy a Mac and change to our Mac version."

 

[Sesam]

In my library the main problem lies where there is an album folder with individual track flac files AND a CUE file (realistically redundant, I understand from EAC ?) , then I get duplicates.

Yes this is exactly my problem too, for an Albums stored as CUE+Separate FLAC files. MC now imports the FLAC files AND the CUE file, causing the duplicates.

JRiver should change the import behavior to ignore the CUE files in these situations. The cue file is really only usable for albums stores as CUE+one single large file.

[Arindelle]

I've hesitated adding something up to now.

I want to ask people with problems a question. [people that have individual files by track +cues]

Are your fields written to disk in the file itself or not?  Meaning embedded in each flac file?

In options Library&Folders=>Manage Library Fields,  are all of your important tags set to "Save in file tags when possible" Most custom fields and standard fields can be embedded in the files. Not only do you have a triple backup of the metadata this way, but you also would have, I believe for many of you, an easy way to not lose any of your tags during these upgrades. Now I may be wrong as I can't test this (or maybe I could ...), but it is worth doing regardless.

If you haven't done that with all the fields that are important to you, you can do it now. Please note that any new fields marked to write to the file will NOT be written to the file until the next time that file is modified. So you would have to copy the tags from the library to the file through library tools to be sure.

So, if one goes and restores a backup with all their tags intact before the problem came into play, make sure that the tags do indeed exist on the files .

Then you have choices! if you

• Proceed to just upgrading and keeping the cues, you can select everything and write back the tags from the files now to the library. Delete duplicates is fast.

• Or you can remove thre tracks from the library and reimport everything - all the embedded information (other than certain fields like playback stats, date imported) would remain intact. 

• OR (which I would probably do personally) remove the cue files, embed any missing tags to the files,  and simply upgrade. (at least for the FLAC file folders) Set the options to not import cue files in autoimport also might be a good idea. (make sure the embedded tags are now in the library

Some people may actually need the cue files however, so the first two might be better for them.

Regardless, always always have multiple backups of both the JRiver library and the physical files when you do massive changes like this (not meaning to be patronizing again, but some people might not do this)

The other post Why Cue files? has indicated a couple of reasons why cue files are still viable and needed for playback and organization/control: SACDs ripped to ISO files would be an example; people that have older DLNA devices that can't handle gapless playback might be another. Otherwise I can't see why they should be imported to the library for FLAC files, even for wav files. There might be a reason to keep them in the folder however (burning, splitting etc.)

Maybe this will help? If anyone sees any problems or omission with my logic, please post back.

Ultimately I am going to follow Arindelle's advice in "Why CUE Anyway?" today and split all my Big Flac & CUE into tracks and get rid of the cue files altogether -- yet more work ...

Just to clarify a bit. That post was actually to confirm what I thought I knew about cue files was actually still the case as I have not used them for over five years - I'm very reluctant to offer advice of people keeping their cue files or not - there could be reasons, but I think for the majority of people, its just because they started ripping that way and don't want to change or that people just didn't know any better. No judgements to be inferred, no patronizing from me. Not everyone wants to "geek" like some of us, after all. The only thing I'm pretty convinced about is that cues have no use for playback and organization of tag information for individual flac files.

If I had one big flac or wav file I would definitely split them whether or not there was an issue with cue files -- FLAC is the best container for metadata ...... but that is my opinion 

I am just a mug who misunderstands or is there a more automatic way to achieve what I been doing manually.

To add insult to injury , my Library is on my Media PC connected by Wi Fi around the house. If I make corrections on my main computer remotely on a "linked" library and then sync with the main library the changes are not made -- I found out the hard way as ever..... For example deleting files remotely does not reflect after syncing in the main library, some Tag changes do but not all . I am confused as to why ....

So I have to sit at the Media PC and make the corrections directly. Any ideas on this one ??

Hey Mike! I can think of ways that would make this reasonably painless for you, maybe you want to post the last paragraph in another thread. Otherwise we go way off topic. You can find all files without going into each folder either through windows explorer search or temporarily importing them as data into JRiver. CTRL+DEL You can google+download "Teamviewer" and access your server from the client .  Very simple to set up and free.  Pretty busy through the weekend though,  its gobble, gobble time

[Funkmeister]

Could someone please explain why many of my albums have "xxxxxxx.flac;1"?  

I understand it's something to do with the cue files (which I have in case I ever wish to burn back to CD for any reason) but I have over 54,000 files in my collection which I've painstakingly tagged correctly and now many of them have these duplicates.

SOME of my albums use the .cue file - where I have one long track, it's great to have the option to 'skip tracks' so I do use them for this occasionally.

What do I need to do (not that I really have time to reconfigure everything I'd already configured...) in order to remove these dupes?  Let's assume I DON'T want to delete the cue files or move them out into separate folders...