Regarding gapless AAC, I'm not sure this is likely with the CoreAudio AAC decoder. Perhaps if I wrote my own AAC decoder (using faad?) this would be an option. Currently Play supports gapless for LAME MP3, Vorbis, FLAC, PCM formats, and Apple Lossless.
FAAD is actually a pretty decent decoder, when talking about features. It support more than just the AAC-LC profile that CoreAudio supports at the time. I believe there is some license controversy about it though. When the time comes to think about implementing it, I think we should have a separate topic on FAAD to discuss this.
Regarding stream vs. track or song. This is a good point. What is more intuitive to most people: the term "song" or the term "track"? I would lean toward track, because although track implies more than is necessarily true, many audio files (e.g. concertos) are not songs, so track seems the better of the two choices.
I vote for 'track' too.
Regarding Layer III vs. MP3, I can see your point. My intention with the format and type is that type is the type of file container, such as Ogg, CAF, or whatever, while format is the format of the audio data. So for Ogg FLAC and native FLAC files, only the type differs. The format of both is the same- FLAC. With MP3, the file's type is MPEG Audio (MPEG-1 audio I suppose), while the data format is Layer III. It is possible to have Layer II and Layer I in that container type as well. That being said, most users are oblivious to this. I could possibly go either way, although I prefer the way it is now.
I see your point. How about showing both container and format? Container first, format second. [MP3 / Mpeg 1, Layer3] or [Ogg / Vorbis] or [Ogg / FLAC] or [M4a / AAC] etc.
The average user will just want to see the container name because he or she will not know the difference. People who want to see both can widen the 'format' column to show both. I agree it is interesting info for the power user, it is just a bit confusing for the average one.
Some extra points:
* Is there a specific reason to have 'Stream/Track information' and 'Edit Metadata' as two separate forms/windows? Most programs use a single option showing both editable and non editable metadata. In a way, number of channels or bitrate is a form of metadata as well, though un-editable.
* When I add a Watch Folder, the OK button stays greyed out. Pressing enter works. Just can't use the mouse to OK it.
* It may be an idea to make a separate low priority thread/process of the Watch Folder scan. When using a larger folder (1000+ files) it consumes all processing power and makes the whole system practically unusable. This is on a G4 so it may be better on of the new multi-core CPU's.
* How about an option to edit existing 'Watch folders'
* Since a few days/builds Play hangs when harvesting a specific newly added Watch Folder. After Force Quiting Play, I have to trash the DB and plist for it to work again. It may be a very specific issue, I'm looking into it now. Maybe others could experiment with Watch Folders to see whether they can reproduce it as well?
* When I upgraded from an older build to build 695, I had to trash the existing sqlite db, otherwise Play would crash on startup. There may be a need for a conversion or automatic trash of the DB for people coming from older builds.
(Using OS X 10.4.9 on PPC)