I am transcribing some vinyl LP’s to flac for use in my Squeezebox Server alongside my previously converted CD’s. About half of the LP conversions are ignored when the server scans the folder on the server. The entire folder (album with files for the tracks) will not work. The files will play normally otherwise, but aren’t picked up for the server database, so aren’t offered by the server. I tried recreating them from the WAV backup, but the same individual files still refuse to work with the server. I check the encoding as 44,100. It seems like some glitch on those specific albums, but what, and why? Again, half of the files work just fine. The albums are all high quality 70’s and 80’s recordings.
Les.
Audacity 2.3.2, Linux Mint 18.3 Cinnamon, Thinkpad laptop, good Sony turntable, and the recommended Behringer UCA201 converting RCA audio to USB.
The first thing I would check, is that all of the file names and metadata contain only normal characters:
Numbers 0 to 9
Lettters a to z
Letters A to Z
Hyphen “-”
Underscore “_”
Space " "
If there’s still a problem, then start working through this list of logged bugs: http://bugs.slimdevices.com/buglist.cgi?quicksearch=flac
Steve, Thanks for the prompt response.
I don’t understand. Is this a limitation of Audacity?
In the 6 albums which the server did accept, I find these in titles: ( ) + : ’
In the unaccepted files, just some of those same 5 characters. No other strange chars.
I see all kinds of other characters in song and album titles in my server database now (from db poweramp and cd’s): colon, semicolon, parentheses, brackets, apostrophe (O’Day), commas, + and =, “quotes”, even the forward slash // which I can understand could cause big problems somewhere. Also many European accented characters.
I’ll dig into the bug list.
No. It’s a common source of problems when moving files between systems.
“Letters, numbers, space, hyphen, underscore” is a set of characters that are supported by (almost) all systems.
“Special characters” can cause peculiar problems because their binary representation is dependent on the character set that the system uses.
Example:
The character à may be hex C3, or hex C4, or hex 00C4 (three of the more common encodings for Ã).
By making a copy of a problem file, test, rename, test, remove / replace metada, test, you can confirm or rule out these possible causes of the problem.
Thanks again, Steve.
SOLVED! I have succeeded in getting several of the bad-actors to go by reconverting from the WAV and being scrupulous with characters. Especially the folder (album) titles, which I believe are the most important. Makes sense, being what the system sees first. So, thanks for the hints. I still don’t know why the dB Poweramp conversions weren’t ever a problem even with various characters. I really like AUDACITY, and will donate.
Les.
As far as I’m aware, dB PowerAmp, like Audacity, is fully Unicode compliant, so it can handle just about any characters that you throw at it. “If only” all programs used UTF-8, this problem wouldn’t exist, but UTF-8 wasn’t known until the 2000’s (first presented in 1993), and take-up was slow, so still some compatibility issues.