Jump to content

Your impressions on the new SS 4.0

Rate this topic


Recommended Posts

Heh! After installation I tried encoding into ATRAC3plus@48kbps. Various music. It seems that it sounds quite a bit better (still metallic, but much more suitable for portable listening while travelling). This may be subjective though.

And then - GAPs!

Link to comment
Share on other sites

Notes I've made so far:

Database usage is generally faster. This is good.

Indigo is good.

The interface still wastes way too much screen real-estate.

Still no EQ. Consider: Winamp had an EQ under Windows95 on 32MB Pentiums. Other players have had EQs for years. In fact, OpenMG Jukebox and SS 1.5 had EQ. So really - what is the excuse not to have an EQ? Some of us use computer speakers, and without a bit of correction for said speakers or for room resonances, things are quite literally unlistenable.

There are still issues with process priority. Certain operations [such an conversion/encoding] are total CPU hogs which bog the system down; others [simple playback] get interrupted by other processes far too easily [and make SS appear to be hung, when in fact it's just waiting for that other process with *normal* priority to finish].

AAC / M4A importing lacks any support whatsoever for tags. This is bad. [Tested with FAAC converted tracks from Fb2k and iTunes created tracks]

Re-importing OMA tracks after re-initialising the database [i.e. deleting everything from the database but not deleting the files, then re-importing the files] requires re-setting the "Various Artists/Compilation" tag for any albums that require such. This suggests that while tags are included in the OMA files, this one particular flag is either not written to them at all or is completely ignored upon import.

Importing MP3s with the "various" tag positively flagged also does not work. This suggests that perhaps importing -anything- with this tag on it will not work properly. Should test with WMA and AAC as well to verify.

Importing MP3s - SS now appears to sort correctly by track number the first time around.

Importing anything - SS still does not set the DATE field for the main library view, regardless of whether all tracks in an album are set to the same date. After re-initialising my library, I no longer have a single album with a date tag from this view. Date tags are correct when viewing by album and transfer correctly when downloading to players as they did before. Is it so hard to implement a bit of code that tells SS when constructing the database "If all the tracks in a particular album have the same date, set the main date field in the database to match"? This is an incredible pain in the ass to those of us who sort our [non-classical] music libraries chronologically.

Still no way to "randomise" playlists.

Still no indication of playlist size or duration when editing [duration available in library views of playlists]

Dynamic playlist displays both duration and size [not sure if it did before as I rarely use this function]. This is good.

"Date Imported" - perhaps in the case of OMA tracks at least, this should be written to and retrieved from the file's own tags? This way, the original date of upload [for HiMD recordings], import, or conversion from another format would be retained [which is way more useful than simply the date the files were added to the current db]. As it stands now, if a user re-initialises their database, all tracks will have the same date with slight variances in the time as their "Date Imported," which is, quite frankly, useless as shit.

Limitations imposed by the library view are, well, too limiting. Classical listeners in particular find this a pain, as it's more common to search first by composer, not conductor or orchestra. While various tagging formats have fields for artist, composer, &c. - and SS does recognise them - they aren't used by the library. This may affect a minority of users, but it shouldn't be impossible to address the fact that many users find the artist/album/date sorting method to be too constricting. Point being: the default view should be more customisable. And no, the "Sort by" option does not even begin to address this [it actually makes things worse, not better]. Being able to easily select sort criteria and their order should be a primary goal for any library system meant to hold large amounts of data [such as several thousand songs].

The lack of file format support is still annoying. While we as users may or may not realise that support included by Sony requires licensing, there are other ways of doing thing. In particular, publishing the details for a "file format API" or something would be a viable option. This would enable users to take open source format plugins and write the necessary chunk of code to allow, say, a FLAC or WavPack dll to be used from SS and for tag support to work. Or maybe I'm naive in what I know about licensing OSS codecs to be used with commercial software. I just don't understand why it seems like Sony find so necessary to make their software hard to use and inaccessible or incompatible with what their users [read: target audience] actually want and use.

Interesting note from SS' help:

Note that the copy protection is added to the following tracks anyway: <UL><LI>Tracks downloaded from a music service site </li><LI><b>Tracks recorded on an MD device</b> or a recording device compatible with certain types of Memory Stick </LI></UL>

Now - after having relaxed the restrictions on uploaded tracks in basically every other sense, why are they bothering to still do this? All they're doing is making life harder for their users, who often don't recognise the need to either strip uploaded tracks of DRM, export to DRM-less formats, or use the SS backup tool - and subsequently lose their own recordings because they have DRM on them that make them useless in the event of a disc or OS crash, reinstallation, &c. At this point, this is simply ludicrous.

Link to comment
Share on other sites


Tag handling: After importing MP3s, since the "album view" of the library has no date fields in it at all, if a user sets the dates in this view [so that things will sort chronologically, which is part of how I catalogue all non-orchestral/classical/baroque/whateveryouwanttocallit music] then the DATE tag on some [but not all] of the tracks [i have been testing this with MP3s since SS2.1] will be overwritten with SS's proprietary, used by no other program I've yet seen date format [specifically, YYYY,MMDD or YYYY/MMDD depending on what you look at the tag with afterwards]. The files it selects to overwrite the tag in appears to be a completely random operation, as it doesn't do it with everything. From that point on, any attempt to manipulate [such as mass-rename] files including the date tag will be corrupted by the presence of this completely out-to-lunch date format they're using. Viewing tags from any other software that doesn't truncate the date field at 4 digits will also produce bizarre and unreadable results.

SONY: If you MUST edit the date tag in tracks that are not native to SS [MP3, WMA, and now AAC] then PLEASE either restrict the date written to the 4-digit standard followed by basically everyone else on earth, or use the ISO 8601:2000 date format [YYYY-MM-DD] which has the advantages of working when truncated to 4-digits as year alone, being easily human and machine-readable, and always sorting correctly using the simplest sort algorithms available. Your date format has none of these advantages [except perhaps machine-readability, though that is questionable since every other program I've tried to use files whose tags have been mutilated by SS has reacted in different ways to your assinine date format].

Better yet: why not have a checkbox under "advanced" in the SS prefs, as there is now for "rename files whose info is edited in the library" which allows users to TURN OFF SS's mutilation [i.e. completely unnecessary rewriting] of tags on all formats other than OMA?


The CDDB lookup feature is next to useless. It will eventually find your tage for you, and its guessing does work, but it takes so long [5-15 minutes for a single 12-track album that is already partially tagged [album name and artist] using a 3Mbps downstream DSL connection and with nothing else running] that I can't imagine anyone actually sitting through it searching for tags for an entire library of files [and then having to approve them one-by-one] .. it would take hours or even days just to do this. I've seen other software attempt this and do so admirably, so it's Sony's implementation of it that appears to be at fault here.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...