For a variety of reasons, I had decided to use Apple Lossless as my format of choice to migrate an 800 CD classical music collection into digital storage. My reasons for picking Apple Lossless were (i) lossless compression, (ii) ability to store album art in the tag, and (iii) compatibility with iPods for portable and car use, and the Sonos music system for home use. (Is there another format that I should consider for these uses? My understanding of FLAC is that the album art is not stored in the tag, and that the format will not play on an iPod. Is this correct?)

The problem I am having has to do with correcting the ID3 tags of each file after it is ripped. For some reason, the tagging software I am using corrupts about every third or fourth file. For some reason that I can not explain (file size?), this only happens with classical files, not rock or pop music. I am including album art in each tag, but the corruption occurs regardless of whether I include album art. I have re-installed the tagging software (Tag&Rename) with no effect. The corrupted files appear as music files on my hard drive, but no program can open or access them.

Does this seem like a problem with my software, or with my choice of Apple Lossless as a format? Is there a more robust tag editor for Lossless files that I should consider? Is there a common workaround for using FLAC on an iPod (with album art) that I should know about?

Thank you in advance for your help.

Jay Chadwick

Afaik apple lossless doesn't use ID3 tags it uses MP4 tags. Could that be your problem?

I did not realize that they were different. The tag editing software that I am using claims to support tagging of Apple Lossless files, I just assumed that these were ID3 tags. Is there another editor that I need use for this?

Tag&Rename supports MPEG 4 files. At least, AAC ones. I have not attempted to use it to tag Apple Lossless files, but it's given me no issues with AAC files before.

I'd email Softpointer about it. They're pretty good about adding/fixing functionality in Tag&Rename. You might want to see if you can make a test file (preferably a small one) and get it to corrupt in some manner, so they can have something to look at. You also might want to check if they have a newer version available, they tend to release early and often. http://www.softpointer.com


Oh, and people misuse the term "ID3" all the time. ID3 is a specific tagging specification for a specific type of tag. It's generally only used on MP3 files. It is not a generic term for "adding metadata to a file", which is how most people misuse it.

For the record, I have solved my problem, and thought I would post the result (i) in case someone else has this problem, and (ii) to see if anyone can give me more specific information about the problem I was having.

After experimenting, I noticed that the only files that were corrupted were those with long filenames. Although Tag&Rename will give an error message if the filename it generates is too long for windows, I was not getting that error message. I also noticed that if I moved the folder where the files were located "up" a level or two in my directory tree, all of the files were suddenly useable. Sometimes moving the folder up only one level would render only medium length filenames useable, leaving the longest filenamed files unuseable. So, I guess there is some kind of relationship between how far "down" the directory tree the files are, and how long your filename can be. By moving my library "up" two levels, and shortening some filenames, all of my audio files now work, without my having to re-rip them. I gather that the problem I was having is some kind of Windows XP filename issue, and has nothing to do with Tag&Rename or my selection of audio format.

Is this a known issue? Anyone have any more specific information about this? I am planning to move the entire library to a network storage device once it gets a little bigger, and want to make sure that this issue does not limit me.

Some windows programs don't like it when the total pathname (full path, like c:\blah\blah\file.ext) is longer than 255 characters.

A lot of references claim that this is a limitation of the NTFS or FAT32 filesystem, or even of Windows itself, which is incorrect. It's actually a limitation of the older file handling libraries in modern versions of Windows. If the program uses the Unicode versions of the file handling functions, then NTFS supports up to 32k character pathnames with a 255 character limit on each directory component. But these are not commonly used and this is probably what is biting you here.

>If the program uses the Unicode versions of the file handling functions

Nothing to do with unicode, NTFS can support 32,000 through the ANSI functions.

Ironically Windows Explorer will have problems with a folder of 255 chars and a filename of 255 chars.

Thank you both for your responses. Do you predict any problems when all of these folders get moved to network storage devices? I was planning on using an NAS drive connected by ethernet, rather than a USB external hard drive.