Four Seasons, The • The 20 Greatest Hits of Frankie Valli & The Four Seasons • 11 · Medley_ Workin’ My Way Back to You - Will You Still Love Me (Tomorrow) - Opus 17 (Don’t You Worry 'Bout Me) - I’v.fla
I have tried 3 different scripts with the same result. I use EAC to change to flac and I can play that track prior to processing. Any clues? I can run a debug if it would help.
This looks like the last character of the files extension is simply removed to stay inside file name limits. You can probably fix it by manually adding “c” back to the extension. Out of curiosity, what’s the complete path that this file is getting saved to?
Hi @Mineo
Not sure what you mean by complete path? Also, if the name of the file in MB is too long to start with, should it be shortened in MB to keep someone else from having this problem?
Just curious, why the double colon ("::") on tracks 11 & 15 but not on track 3.
Also while a different release (or re-release) should it not be in the same release group as the other release?
Hello @dashv
I will take a look at why the double colon is there and also look at the RG. Next I’m going to try to simply change the fla to c in the extension. So I’m off line for a bit. Ta Ta for now.
The filename you’ve posted is 202 characters long already. The limitation in Windows is 256 characters (or is it 255?). So you could easily be running into that limit. One thing I’ve seen people do in naming scripts here is limit song names and album names with statements like $left(%album%,30) or $left(%title%,50).
.fla and .flac are the same format and structure like .jpg and .jpeg. NERO saves as .fla on some versions. You can safely add the c to the end of the files or place a bat file in the folder containing
ren *.fla *.flac
and double click it and it will do it automatically for all .fla files in the folder
As to why it is happening I think others have answered that.
Actually this is pretty strange, Picard should not do this. It explicitly is taken out the file extension out of the filename shortening. So at least it’s supposed to keep the extension as is.
@Llama_lover: Seeing your complete file naming and the complete file path could help getting to the core of this issue. If Picard is really modifying the file extension I’d consider this a bug.
Thanks to all of you for your input. It may be a combination of all the above. To start with, after the EAC change to flac it goes to C:\Users\NewOwner\Desktop\EACEdit\EACED˜1
I put the files into my edit folder to review before I run them through Picard. After they are processed, they stay in this folder for reinspecting prior to going into my Windows music library. For whatever reason, I am unable to just add “c” to Fla. Maybe due to the length of the file name (Still working on that).
@Mineo’s, @dashv, and @Billy_Yanks posts did cause me to take a deeper look into my process [thanks, I needed that]. So square 1, after ripping in EAC I normally pull the files or folder directly into Picard. This time I checked each file BEFORE processing. I found track 11 was titled a little bit differently than the rest of the tracks. Highlighting #11 and clicking properties-then type of file it shows (FLA). all the rest of the files show flac… If I now try to play track 11, windows says it doesn’t have a program to open that file (FLA) and to tell it what I would like it to use or search the web. So now I will investigate if it is EAC or Windows that is causing the problem. It is probably not Picard.
I am going through 2 computers. One is Windows 10 v1508 and the other is W7 with all the latest updates. Both have the latest EAC and Picard versions. One “funny” thing is sometimes the medleys #3,11, 15 all fail to process correctly on W7, yet only #11 fails on W10. I have 4 other cd’s each with one long track name that have given me grief in the past. I will now spend some time seeing if the problem is EAC or windows and post my findings.
Many, many thanks to you all for making me rethink this!
As a test, try removing 20 characters or so from the filename, then see if you can add the ‘c’ to the end of the extension and play the song. That would prove or disprove whether the problem is a long filepath. If it is the length, then limiting the length of the title in your file naming script would probably be sufficient to prevent this from happening again.
Just make a new folder called *C:\RIPS* and point EAC at that location. You’ll save yourself a big headache then. Working from folder deep on the desktop wastes so much of the path name.
So as you all pointed out the file name is too long. @IvanDobsky creating C:Rips solved the problem in Windows 10 without shortening or changing anything else. In Windows 7, I still had to shorten the track name by about 15 characters. Might be a diff in the amount of chars you can save between the 2 operating systems. [Or Pixies.]
@Billy_Yank, yes, removing 20 chars did take care of the problem. I shortened $left(%album%,30) or $left(%title%,50) as you suggested and that also worked. [Prior to changing my save to folder]. I can add back a few characters to the title if need be for some releases.
@The_King & @Mineo I still had to delete a few characters to add the “c”. It would then play properly.
@dashv Still not sure of the double ("::") and release group but will dive into them this weekend.
You have all helped me to determine the problem and pointed out the fixes. I appreciate your time & knowledge. Oh! After applying fixes I was able to process my other “problem” tracks.
Must be Pixies as max path length should be the same in win10 and win7 at 260 characters. And yeah, it can be hacked around and extended but that direction leads to dragons as then other applications will get confused.
Safest bet is just to keep it in your head to stay under 250. I generally try and keep them much much shorter as I know I’ll want to move the album after tagging.
This points out that you have 8.3 filenames enabled or required depending on what file system you have chosen to use. This extra filename added to the LFN entry may be eating up the rest of the filename space in the allocation table or is confusing picard if it pays attention to the 8.3 name. It is also known to have problems with paths full of incredibly long filenames.
@The_King & @psychoadept WOW! Thanks for sharing that info. I am digesting the links and will use both to make fixes on both operating systems. I really appreciate the extra time you took with your responses.
Be aware that @psychoadept’s edit for opting into longer paths in Win10 may confuse other apps who are used to the old limit. Not everything will expect paths to go beyond 255 chars. I’d still trim my track filenames.
Seeing C:\Users\NewOwner\Desktop\EACEdit\EACED˜1 is not that odd I have seen that happen when copying paths as the old 8.3 names can be produced from long filenames for older DOS compatibility.
For example on this Win10 box I can reach C:\Users\Ivan Dobsky\Documents\Long Folder Name\ from a command prompt using short names.
The folder I end up in is C:\Users\Ivan Dobsky\Documents\Long Folder Name\ but as I walked there using the 8.3 names I see the 8.3 path in the prompt.
So you have backward and forward compatibility lurking underneath…
I agree there is still a possibility of needing 8.3 names that is why I stayed netural about having it enabled but something to take into account when troubleshooting problems dealing with long filenames. It is for the user to decide after studying about it independently . I leave it enabled on my system drive but format my data and backup drives without it and much larger file allocation sizes for performance and space efficiency reasons.
Hi to @The_King & @IvanDobsky. I will take all into consideration. Along with your helpfulness I finally remembered what a “tilde” is and what it means. lol. Thank you.
