JustAnUnCoolCat

Well, in my case, i usually hit the probs when i am doing kind huge bulk transfers.. like when the whole batch job goes into hundreds or thousands of tracks Then again, i dont think the designers of SS really ever anticipated a HDD deck user ever doing a huge batch in one hit on that kinda scale (it's an overnight job, if transcoding on the fly too). But it has happened to me before on more moderate, normal scale transfers when i have sent a mere 6 CD's worth of WMA LSL rips to transfer OTF to a Hi-MD unit - so it more or less discounts a flaw in the deck designs to me 'Tom Kat'

Well, if you take Sony's tech info as being vaguely accurate (use of various supported codecs.. being non-device specific) .. The running time specs (aka battery endurance) on most ATRAC devices is based on the use of ATRAC3PLUS nowadays, where the benchmark the power measurements are based on either 48k or 64k ATRAC3Plus (i forget which, probably 48K). But it's pretty much the case that, in my experience of Hi-MD and D-NE series CD and the NW-A3000, that opting for ATRAC files to use on the decks pretty much brings you damned close to the kinda figures Sony quote. Put it this way, going from my experience of the D-NE1 (the original ultra-long endurance ATRAC CD units of the first-gen variety) - my unit (using ATRAC3 132K primarily) met and exceeded Sony's figures regularly.. it was only the times i was forced to ramp up the phones volume hideously and use EQ and the MegaBass (or whatever they called the bass enhancer) that the figures dropped.. and a moderate use of those two things brought the figures back into line with the specs. Note, in the D-NE1 instance, i never used the external back pack.. purely used the internal cells packs only. Notably, MP3PRO's (played back as 22Khz full-bitrate-range VBR MP3's aka MP3PRO VR in legacy mode) dont fall far short of low-mid bit-rate ATRAC files for impact on battery life - note, i mention this as it comes to mind, i know i'm probably the only one here mad enough to use MP3PRO in legacy playback mode as a MP3 source... (however, when on a long trip, it sure eeks out the battery life when using carried over mp3 cd-roms if they were mp3pro encoded). So i would say if you are trying to eek out the max endurance on the deck of choice, definately go with ATRAC file use. Now clearly, when you go into ATRAC3 105/132K and the 96k+ ATRAC3PLus rates, you may not find it so clear cut vs the other supported codecs. Beyond that, i guess you are just gonna have to test and assess for yourself Be Cool Always 'Tom Kat'

Well, two things worth noting.. WMA LSL source files will, for ANY Sony ATRAC unit, be transcoded on transfer according to whatever 'if it cant transfer, convert to....' settings you have in the transfer settings in SS. I use WMA LSL as a more universal LSL (more universal that ATRAC LSL anyway) general codec, so i know the score from experience. OTF, on a bulk transfer, is kinda real long and slow process, so really you are way better off literally importing the files into SS and setting it on a batch conversion process to convert to say ATRAC LSL with a preset quick transfer ATRAC setting. That way, you dont hit the second most temperamental issue with SS, the fact that SS has been known to reject some legit files as being non-transferable (despite the fact it's been told how to handle em) during bulk transfers for seemingly no apparent reason. Now the odds are, if you left the transfer to complete, then one by one, re attempt to transfer the rejected items, SS will do em just fine. So i think it's pretty much a suspicious paw that points to SS Me, i go with the pre-batched method (batch convert overnight on what would be a big bulk transfer/transcode op), then i have readied ATRAC LSL copies that i know will quick transfer to a preset lossy ATRAC version when sent to the device. However, do ensure the files (the WMA ones) are not copy protected (i believe, unless my failing aging grey matter is really gone south, you can still inadvertently copy-protect WMA-LSL files during ripping in WMP.. or similar) - if they are CP'ed (DRM Protected) then SS will reject them outright.. all the copy protected ones anyway.. Hope that gives you some insight.. 'Tom Kat'

Nice idea, if it exists..?? Not sure if it does, as yet - and whilst it's a brill universal method, it's limited by the fact that not all ISP's carry all the alt.binaries groups .. ditto for the NNTP specific providers (that said, most independent NNTP specific providers do carry the vast majority at least). I was about to add that since it'll be (in NNTP terms relative to the rest of the binaries groups) pretty damn low occupancy and demand, maybe if the group existed or got created, it'd probably never get the vote or approval by many ISP's if it was an 'to be added' request since the average ATRAC user base is pretty low in numbers. But i'll retract that observation, and simply say... if anything, the usage will be low and maybe unattractive as an 'to be added' group to many ISP's NNTP list. In revision, i wont completely write it off though as a non-starter, after all there are plenty of zero-occupancy or ghost-town groups still floating around the kept lists... and many aint been posted to in years.. such as, alt.binaries.sound.vqf - in fact, the last time i saw a post in that group, was a multi-post of sample encodings i sent to it for a closed group test.. (was easier to distribute the VQF versions that way). That was about two or so years ago. Well, if the interest is there, and enough users get their ISP's to carry the group and it exists or gets created, fair play... i'll recognise it as a more serious contender Bear in mind, i do realised there are high-retention subscription access servers out there that hold most groups - but not all of us use them - in fact, the vast bulk of users of NNTP dont use the paid-access servers at all unless they are the harvesters of the proverbial dodgy content. In fact, i reckon it's the fact a lot of the subscribers want the high-retention server access to fill their dodgy stuff desires, that keeps the old paid-access servers a going concern. I'll buy music (that's totally a fair-play thing), i'll use a bundled access to NNTP via my ISP's or equiv on other ISP's on other people's accounts i often have permission and usage of - but i doubt i'd shell out money to access a subscription access NNTP facility otherwise, simply aint got the necessity to go do that. I'm sure there's an option out there we've all overlooked, probability says there's gotta be, just a matter i guess that when we can fit it into our 'we do have lives outside of the forum' free time... that we uncover the elusive answer. *sharpens the claws, in prep of yet another forensic shredding of the as-yet-unfound holy grail* 'Tom Kat' 'Tom Kat'

Hey... another cool dude radio peep...?? At a rough guess, i reckon there's plainly and simply a meaty enough amp in the A series to drive the HD model phones - you may have to run the output up a bit higher, but that would be about the norm with heavier duty cans. The Sen's i use (EH2200's) do ok on the A3000, enough drive to run those - and likewise the Medusa 5.1 cans (using inline 2-channel adaptor lead.. so the phones become 2-channel multi-driver cans) worked out nicely... but they were struggling a bit as in that config they need quite a bit of drive to bring em to life. If you aint an EQ user, and find the output level (turned up sufficiently to drive preferred cans, without hitting distortion etc or stressing out the amp) to be lacking, i'd suggest that if the cans have an inline vol control, then connect the phones to the phones out on the A series and switch the A series's output setting to LINE. You lose the EQ, and on player vol control, but there's then a nice little boost that ensures the player can drive some of the more meaty and heavy-duty cans. 'Tom Kat'

Mine also, came in the fancy violet colour box.. Speaking of bubble packs as mentioned... yeah, dont half make it all look a bit tacky - mine you, the only advantage (from the consumber POV) i can say for bubble packs is that you get to see just how tacky and cheap or lovely and smart the product is when you dont otherwise get to see a display example. Bubble packs, yep.. certainly a pain in the wotsits (a bit like a kick to the male dangly bits) to open. I remember the time i once bought a bulk pack of alkalines to stick in my rucksack for cycling (for the lighting) and one dark night.. one dark, cold.. near freezing, night i had to call on the spares in the as-yet-unopened bubble pack. Much swearing, cursing, and many many iPod owner's souls were offered in a proposed deal with the devil as i wished i had a knife with me, as the plastic packing was damn near bulletproof and flawless in the seams. Took three hours, in the cold of night.. at the roadside, and one old sharped key (labouriously sharpened using the nearby kerbstones) and mucho repetitive scoring of the plastic to get the offending packaging open.. to then go spill all 50 bloody cells across the road I always have a craft knife, stanley knife or such like on my person these days to ensure that never happens again in such situations, and for sure, it's a total necessity when it comes to bubble packs 'Tom Kat'

Ok, can we kinda take this from the top...?? Firstly, were the files in question (the WMA's) copy protected, or former copy-protected..?? Secondly, were the files in question all ok (previously) for transferring to a device/burning to ATRAC CD or Audio CD/Recording to MD via SS without transfer errors or the need to transcode to ATRAC..?? (With regard to the last question, treat in context to your destination device and the mode of transfer that applies.) Thirdly, were the WMA's files that were (at some time) transferred to a WMA supporting ATRAC deck (A3000 being an example), and subsequently uploaded back to the PC via SS from the ATRAC device..?? There is a rational reason for asking all those question, no.s 1 & 3 being quite critical to determining the prob. 'Tom Kat'

About the only time 'neckband' cabling ever proved useful for me was on phones where it was supplied such as on MDR-V series stuff and others. The big diff being.. 1. They have even length cables past the split point (where the two sets of two-core on the one cable pair divide) - hence avoiding the bud uneven cables issues/ 2. The cable is substantially tough, real tough. Great for relaxed listening, great config for when you wanna drop the cans off your ears and leave em dangling.. such as to answer the phone. Downside..., and i bet even DJ's have done this before, you sometimes forget they are there when they are dangling.. and if you forget and walk away too quick from what they are plugged into, you get a nasty shock as the phones shoot up and whack yer neck... *hangs head in shame, having nearly strangled self more than once that way* 'Tom Kat'

Got no idea, since i never did that trick with either the D-NE1 or the D-NE20.. However, you should realise that the 'backpack', aka the belt battery holder, is intended to extend the running time of a deck, not replace the internal cells. Now i have never taken one of these D-NE's apart, but i highly suspect that it's been electrically wired to expect to find a circuit across both the ni-mh 'gumstick' cell compartment as well as the ext pack when the ext pack is connected. After all, consider this - if you have both connected, the estimated running time left (in terms of battery endurance) the unit decides it has based on demand and battery state, is a combined figure when both sets of power are connected, or the individual total of the 1-2 cell packs (depending on D-NE model) when running off internal power source. So it would make purrfect sense to me, logically and from an engineering POV, that if it expects to see internal+ext present or just the internal set present, connecting just the external with internal cells missing, wont meet the circuit conditions the electronics is expecting. Someone will surely tell a diff story, hopefully they'll actually know how the units are wired for power if they do happen to dispell my theory. But i think mine will prove to be the case 'Tom Kat'

Frustrating..?? Hell, the method i outlined, the use of dBPowerAmp, is about as frustrating and time consuming as... making a cup of coffee. In fact, i use the tag refresh a lot to unify tags on huge batches (around 2000 tracks a batch), and it's certainly no hassle to set the ball rolling, go make a coffee or three and go read a book or something. The odds are, it'll be done way sooner than you anticipate, certainly i aint complaining - bets the hell out of the generic smelly stuff as a method vs having to do lookups in SS on such a batch (50 tracks at a time, in SS using lookup, is slow beyond reason). Certainly is infinately quicker than doing the job by hand *shudders.., the memory of tired and scorched virtual paws from a mass hand-tagging of 1000+ tracks in one session, is the stuff of nightmares and plain hell on earth* 'Tom Kat'

Yep, for sure, holding and providing downloads on the main site host would definately chew up the old bandwidth... I remember how bad alone, and just from an ever increasing user demand for forum/portal access (downloads were another kettle of the generic marine life entirely) rapidly over a year or so caused bandwidth exceeding situations and an every growing need for more flexible limits and space and mostly high capacity on the connections side. In fact, as the owner of that portal and his close friends will tell you, it sure helped to have donations .. as the evolving hosting bills went through the ceiling to meet demand. But hey, in a way, it's not such a bad thing that ATRAC device users are a small subset of the portable audio community, it's that which helps ensure the demands on sites such as this never go into freefall 'crash n burn' over demand far exceeding capacity.. Mind you, i wont speak that wisdom too loud... stranger things have happened than one person draw such a conclusion.. and it's soon followed by a massive bandwidth hit 'Tom Kat'

Maybe it's someone's hosting, otherwise unused, that they allowed to be used to host the download, and the link on the downloads page points to it..?? I guess if it's a real concern to you, you could always post this over at MDCF too, since it was an MDCF users project that produced the Full download version (hence the MDCF in the filename). I'm sure they'll put you straight over if it's a security risk or othewise dodgy.. 'Tom Kat'

Well, as you can see from those pics (which, in exposure terms, pretty well demo the colour of the violet unit well), it's hardly garish.. and definately no worse than some purple shades used in some clothing. It's ok by my way of thinking, hell i have a violet one.. But then again, i aint fussed - i kinda agree with a nice bit of film soundbite philosophy from the file 'Alfie' - where the character comments that when you are comfortable and self-assured about your masculinity, you can wear practically any colour and no feel any less masculine for it 'Tom Kat'

But.. If you dont fancy doing the dastardly manual tagging ;) You can download dBPowerAmp Music Converter, the MP4 plugin (both free), and download the free release Nero Digital Audio codec (which is Nero's MP4 handler) and follow the instructions for installing the enc/dec as posted at the MC's website. Then, you can use dBPowerAmp to refresh the tags of your iTunes downloads/rips to suit. In fact, SS 4.01 (the Jap version i was messing with earlier, the new one if i grabbed the right item.. and forced to install) picked up on the default mode of tags that dBPowerAmp writes/tag refreshes MP4 files with. Don't know if dBPowerAmp can handle protected audio mind, re MP4 mode files, but probably not. But it's not rocket science to get around that lil ole prob Maybe i got lucky, but some MP4's i imported into SS 4.01 imported with tags intact fine earlier Hope it helps 'Tom Kat'

BTW Folks, i think i managed to locate a japanese 4.01 updater, and maybe may have figured how to get it to install into an English lang Win environment. Will post back later, one way or the other... *scarpers, kinda hard to do with all virtual paws and claws crossed hoping for a lucky result* 'Tom Kat'

Yep, those are indeed DB files, exactly whether they are redundant or not (aka they may not be the current copies the app is using when in use) i guess you could tell by their Date Modified info associated with the file. If the Date Modified, or even Date Created, after you close down an SS session shows the day's date and time within mins or about half-an-hour (depending on what was going in re library etc in SS), then do indeed err on the side of caution and DO NOT DELETE unless you know different that they are redundant. Now the fact they are in the Gb size region could be reflective of a lot of redundant data within, and also combining with the fact you have a massive crap load of entries that are current - this would explain the sizes somewhat. Inside SS, you can tell it (under options i think it was) to go optimise the library, which should then remove most redundant entries (associated with content no longer in place in the library). If the sheer size represents a lot of redundant data, that'll take it down a bit in size. Alternatively, you could simply try deleting (from library only) all your current library stored content, aka not physically delete the audio file content itself, optmise the library, then reimport the library content back into SS. Alternatively, you could mess with the registry and associated data files that SS references to tell it where to find the library files etc, and store all data and content on a separate drive entirely and tweak the reference data files/registry to point to the corrected alternative paths. I'll leave you to figure out how-to and how that works, the techy bit, as i did it myself when i dumped all source and ATRAC content i use onto a NAS drive on the network and also relocated the SS install so it totally coexisted on the NAS. Unfortunately, if i had to repeat it.. or even try to describe how i did it, i'd be one sorry virtual cat spirit.. as i plain forget what i tweaked, and as such can't guide you in that direction. Was a good idea at the time (apart from the fact that access via the NAS drive is notably slow vs a local drive) - must make a memo to self to re-employ old principles and document such changes and methods Yep, getting older... greyer, and less reliable about documenting stuff... Good luck 'Tom Kat'

Good points mentioned by all, and yes.. when it comes to audio quality as reproduced, it's a highly subjective thing God knows, if you took the words and conclusions of the highly-revered reviews of 'AP' kit in mags such as What Hi-Fi as being the gospel absolute pinnacle of 'what is, what shall be, anything less is garbage', you'd find yourself in a spiralling debt situation trying to achieve such perfection Let's face it, in reality, anything playing lossy audio is never gonna be comparable in any shape or form to listening to the same audio at source from a true original mastering unless the source and lossy audio comparisions are 1:1 (aka comparing an MP3 original such as a promo from a band on xxx reference kit vs yyyy lossy audio player.. and accounting for lots of miscellaneous and lots of critical factors that sep the two audition sources). So all lossy audio playback units are flawed by default (not that you'd believe that if you happen to be a huge fan of the AP mags.. of which the one i mentioned previously is definately an iPod slave, where they virtually treat it as the perfection of portable decks). In my travels, doing lots of remastering and restoration of audio (meaning, in effect, i aint a slave to the 'if it aint digital at source, it sucks' mentality - whatever works, works for me), it's plainly obvious that many embedded audio player implements are fundamently 'added value' add-ons giving extra features to units which fundamentally aint designed to be audio decks by main intent. So when you consider that, and notably listening to audio decoder/player implements in DVD players stands out particularly, it's a total mixed bag what you are going to get. I happen to like the lossy audio decode/handling implements in Sony kit, kinda feels fairly neutral enough when it's used without EQ back to an AP grade amp and HQ commercial installation speaker setups (the ones in question, speakers i mean, are equally usable in a studio let alone for their main use, in halls etc and walk all over most mega-bucks shopping mall/centre drivers) using the analogue line-out setting/connector. Likewise, whilst it's imperfect (as always, aint a perfect performer out there.. that's a definate), the phones out on a Sony usually makes a nice balance between AP desires and portably practical performance when listened via half-decent phones. Now the exception to the 'nice sound on a Sony', that sticks out in my mind, is the W800 series phones - maybe the owners love em, but to me, the output sounds a tad like the audio output of a lossy DAP from about two gens ago. That said, in fairness, the phones you use with a W800 series are not exactly brill reference stuff, so possibly the audio player implement on that series may be better if you can work in a decent pair of phones But, and i really dont wish to sit down and detail the various phones w/audio players i have used and listened to (i have a friend who works in a service centre, so i often get to listen to examples of phones), but i definately came to the conclusion that it's a simialr mixed bag to say DVD players and their lossy audio player modes. Usually using their stock cans, they stink big time, unless for some reason they come with OEM examples of the better walkman type buds or phones. Personally, i reckon you just gotta take audio players on phones for what they are, an added-value feature - it's a bit much to expect a thrown-in 'taking advantage of a situation' DVD players's MP3 decoder/player to sound even close to a good well-developed straight PC-implemented mp3 decoder/player using a half-decent sound card and comparable speakers. And likewise, i consider that it's really not fair to expect a phone's audio player implement to match the performance of a dedicated 'by design' purpose built audio player. So the 'they stink' (using the typical crap phones bundled) conclusion i have of phone based audio players, is a purely perception based thing with a touch of 'omigod, could they be any cruder.. or more fundamentally basic' amazement over the UI and the in-player operating modes (feels very 1st gen DAP to me usually) - same goes for the average lossy DAP mode of DVD units. So if you aint expecting miracles, a phone's DAP may be find - likewise, you may be happy with the performance when you weigh up portable and practical combined facility in what is a compromised affair in usually unfavourable listening environments. But i really long (many moons ago, too many to recall) realised that the add-feature implents of audio player functions on devices not initially destined to be mainly audio players are chalk-n-cheese vs dedicated units. That could easily be a different balance, in practise, but at the mo.. they are like woman and men.., they co-exist.. but often tackle things with a diff philosophy and purpose. I'd also question, seriously, whether 'AP' phones are a good mix with any phone or add-feature audio player device. In many cases, dumping a pair of AP-grade phones (and remember, the AP grade is again a perception thing) on such a device can a be killer or reveal some suprises.. They can often show up some serious deficiences in a unit, as many added-feature audio players and the audio circuitry on the device they are implemented on, is tailored or optimised to suit the intended type of phones that will be supplied. And given the environment where many phones are used, it's almost certainly 'buds' (conventional or canal type) used by choice and for the most part (i know there are exceptions to the general norm, some very HQ buds... but megapricey too) i'd hardly put the type into the AP phones/drivers category.. as they are, by design, a serious compromise by design. Ramming a pair of good AP speakers onto a bedroom mini-hifi system is often a dissapointment, likewise when you substitute a pair of monitors instead.. as they are often cheaper marginally, as you soon realise that why you aint getting the performance you expect is because the amp has been worked to suit the intended driver units.. not your preferred mega-bucks super-duper replacements. Much the same can be said for AP phones really on a mobile phone's stereo audio output. Also, given that many AP grade phones really need a quite substantial drive to make em come to life .. not big milliwattage output... but a pretty well balanced and not-strung-out amp at least that operating well inside it's capability, i wonder just how well a pair of good cans would fairly reproduce the output.... Sure, there is the inline phones amp option, if needed - but given the output of a phone's stereo port is often erm, not clean and sterile/neutral noise-wise, it feels a bit like a receipe for disspointment to go that route. Surely, noone really whacks a hi-gain phones amp onto an inherently noisy pre-amped output do they.. - outside of the AP world i mean..?? For sure, given you have the socket and adaptors to suit, whack a good wide response pair of neutral high SPL phones onto the phones out of a DVD or audio player on a phone, and you often notice a heck of a lot of unwanted crap coming to life that your average buds supplied never show up. To add, then, a nice meaty phone amp.. is kinda audio suicide unless it's got NR function built in (but remember.. the NR function in such amps.. is inherently destructive on some level anyway). Hell, if the person who started the whole 'My sony sucks vs my phone's audio player' wants to consider his phone to be the dogs wotsits/male-dangly-bits of the portable audio world.. fair enough, but if there was a real 'scream from the top of a hill' reason to condemn a Sony by comparison - then there is such a thing as passing your comments and critique to Sony maybe... not the forum, after all.., we aint gonna be able to fix any issues that may be the case re the Sony decks themselves *feels the need to go soak the red-hot and smoking virtual paws* 'Tom Kat'

Well, the question of HE-AAC support was a valid and previously questioned aspect - it occurred within this forum before i brought it up again.. and the simple fact that SS 4.0 did not support HE-AAC directly was not absolute proof of device implementation or not, as if the transfer manager is not handling the audio correctly re determining it (through a lack of support capable of recognising the diff between HE and non-HE AAC encodings) then it could easily be rejecting the HE audio regardless of device support. So it's still a valid aspect to explore, of which we will only know for certain when SS 4.1 becomes available. I certainly was not skating on thin ice, or treading a thin wire, in my mention of AACPlus/HE-AAC in an analogy to MP3/MP3PRO transfer handling. All i was saying was that where the AAC version of similarity/compatibility was passable enough (and if the AAC handler in SS was up to the job and likewise in the supporting codec implement in the destination decks - be it legacy mode or direct SBR/PS supporting) that it was not beyond reason to be able to allow the SBR/PS and SBR encoded AAC audio to transfer untouched. I was not directly comparing MP3PRO and HE-AAC and AACPlus as being 1:1 comparable in their content and implementation of encoding and subsequent decode demands - sure, where they are entirely different alien beasts (the SBR and SBR/PS versions) that maybe only share a basic header and container component but otherwise very different in the decodable aspect, then the passing aspect and subsequent device handling is a whole different ball game, and then in such an instance, not straighforward. As for HE-AAC handling on the A series, and your conclusion that there is no implentation on the A series due to it being older than SS 4.1 ... Firstly, the relative age issue is not proof or conclusive reason to discard the question as being null or pointless. As you should recall, the A series decks preceed SS 4.0, and a firmware implement was used to bring AAC support into the A-series and the flash decks. So whether the decks can decode HE-AAC is not dependent on SS's support, SS's support only restricts (due to handling) the transfer permission/tolerence. So unless there is zero implemented HE-AAC handling in the device firmware, the question is still open and valid. If the firmware is not implenting HE-AAC support as yet (questionable, since we can't get such AAC transferred to test with .. and outside of official confirmation to the effect, that's the only other way we'll know), then that's still not a done deal that an predated deck cannot be retrofitted.. they already did it to a wide range of decks for SS 4.0. vis a firmware release, which in itself was almost uncharacteristically non-typical Sony policy (they usually implement in a new model and force you to buy a new variant to get there). I'll wait til i get SS 4.1, and test for myself, and explore dealing with Sony directly for official confirmation i think in the meantime. Guess maybe i was seen to be out of line to bring up such things in these hallowed circles, well where that's a prob, it's in the eye and mind of the beholder.. not mine 'Tom Kat'

Simple answers to clarify 'gapless' in the ATRAC Walkman implementation means, it plays seamlessly.. but this is only an absolute for ATRAC encoded audio, in other words.. if it's ATRAC it'll be played seamlessly (literally meaning the audio tracks will be played as though they are appended to each other in one continuous audio stream, if there are trailing and leading gaps in the audio segments/tracks that make up the stream, they'll also be present). Seamless type 'gapless' playback means literal playback - so if you encode a set of audio tracks where there was intended to be intermediate literally pauses that are not part of the encoding (for example, CD's with 2 sec track gaps), then when the audio is ripped/encoded, the non-internal gaps will be lost. However, if the source was literally seamless, such as DAO style CD's (aka the type of mastering such as concerts and many classical suites, where one track leads straight into another, or say dance/DJ mixes - then the audio as heard in it's ATRAC resulting encoding will be as seamless as the source). WAV sourced audio, and likewise WMA Lossless, imported and converted to ATRAC will also play seamlessly with no added artificial gaps if they were seamless to begin with. Any empty non-content artificial audio frames (pure digital silence) each end will be (if they existed in the source) maintained. MP3 sources, as these have trailing null frames, will (when transcoded to ATRAC) still have the trailing null frames content in the ATRAC versions - if you dont remove the nulls, you wont get seamless playback less those nulls. So if you want MP3's to transcode to ATRAC, and lose those nulls that would be included before and after encoding, you'll need to decode to WAV or other lossless format, go in to the resulting decodes with an editor, and strip the unwanted null frames and resave to WAV or WMA-Lossless to then be able to reinsert these (by import) into SS for subsequent ATRAC encoding. If you have Sony edit software such as Sound Forge, you can do the edit/decode direct in there, and using the ATRAC plugin, directly output the edited results into ATRAC form ready to import into SS after changing the output filename extentions to .oma or .omg It's pretty much that simple As for NW series decks and their handling of WMA's, MP3, AAC - well, it feels like the A series handles WMA's properly and seamlessly where the audio is seamlessly cut to start with but i am basing on non-technical testing (must add that to the to-do list). MP3's will be handled as-is, and hence there will be a pause due to the inherent null frames in MP3 audio when relying on playback of MP3's sent as MP3's to the decks. No idea re AAC at this stage, but i suspect they will act like WMA's sent for native decode/playback on the A series since AAC's dont usually have trailing empty null frames unless they were part of the source audio the AAC's were created from. Clearly, if the source had nulls on the end and the source was AAC encoded, then they'll act (in seamless terms) much like mp3's do when sent for native playback to the A series. Hope this helps.., and over the weekend, i'll sit down and do all the testing to correct/confirm the unknowns here.. and hopefully by Sunday night, may be able to submit a proper conclusive tested outline. But as i recall from the D-NE series, re mp3 playback, and i suspect this maybe the case for the NW flash and hdd units too, you'll probably find the artificial pause between MP3's in transition to be notably less than occurs with most mp3 supporting decks. In fact, with the D-NE series (2nd gen & 3rd gen), there is an artificial gap still on playback, but it's so markable reduced in durations vs that of most mp3 decks, that for the most part all you'll ordinarily notice is the the trailing nulls of the outgoing track plus possibly one or two frames worth of nulls (which adds up to bugger all). Clearly. mind, where you have instances or retained null frames in the audio (any format supported) and/or artificial handling transitional gaps/pauses inserted by the deck (MP3/WMA/AAC formats played natively usually), if you are listening to audio that was intended to be seamless in transition at the original source mastering, then no matter how small the nulls/transistional gaps are, you'll hear a perceptable drop out as when you hit the null frames and/or the whatever degree of inserted transisional gap sourced from player handling. Hope that helps.. Be Cool Always 'Tom Kat'

Well, i guess re AAC support, on the players applicable, and support for HE-AAC as mentioned in CP 4.1 :- 1. We may at last be able to put to bed the real question standing of whether the AAC-supporting decks actually do support HE-AAC or not. We really couldn't be certain, in some ways, since if SS was checking (referring back to using SS CP 4.0) the codec and content type then it would almost certainly have found many HE-AAC's were non-transferrable since many HE-AAC's have a nominal bitrate (talking VBR's here) nearer 64K than the min stated supported rate of 80K that the support notes of say the A3000 note with regards to the firmware retrofit. 2. SS itself, in CP 4.0 form, may have actually inhibited non-trancode transferred for the above reason if the files in question were HE-AAC due to not knowing how to handle them as valid transferrable content. Ok, it's certainly no bit of rocket science to examine an HE encoded file, ignore the bit that tells the app it's HE-encoded, and pass it still regardless provided it's within a supported bit-rate range. Proof of that, simply, is the simple fact that MP3PRO's can be sent as MP3's despite the fact they are SBR-encoded (as long as the sample rate is in the right range supported by decks and recognition by SS). I mention this because, despite the fact mp3pro is not supported, it is for test purposes, a proof of principle that SBR and PS (such as HE-AAC/ACCPLUS) mode encodings can be passed and sent provided they meet the supported bit-rate and sample-rate restrictions.. But did anyone at Sony, or whoever constructs the soft on their behalf, realise that..?? I doubt it So to close my AAC comments, great if it's supported fully (HE-AAC i mean, after all.. it'd be a ludicrous thing to offer say CD-RIPPING to HE mode in SS 4.1 if you cannot send the files to a suitable deck without transcoding) - if the support is there (both ways) then i'm sure there are gonna be happy cat spirits within some of the AAC use fans in the community who will be purring inside. Whether i use such support, depends highly on whether both soft and the firmware of the A3000 will or does support HE mode to both SBR and PS modes (aka AACPLUS) - if it does, great, can finally have a decent low-bit-rate audiobook encoding combo and likewise great for taking the netcasts grabs walkabout to evaluate when away from home WMA.. and Bulk Transfer.. in CP 4.1 I wonder if anyone noticed this, and if it's a mere 4.0 quirk and fixable with 4.1 or simply a prob with bulk transfers... re WMA's. Was transferring a batch of 48 WMA's (WMA9 standard and WMA8's aka encoding types as used for WMA download offerings, all CBR in my case), and SS rejected two of the tracks. Notably, earlier in the day it had done this with 4 tracks in another bigger Albums transfer (in that instance, selected 10 albums to send in one hit). All the files were 44Khz. Now the interesting bit is.., i set SS to transfer without conversion, and to not transfer any that were unsuitable without transcode, purely because at that time, i wanted them to not be auto-transcoded to ATRAC. And there was no reason, at all, why any should fail to be suitable and require transcoding for transfer. They were all home-produced ex-DRM's (aka i had DRM encoded home-made audio .. some of the stuff i produced to demo local artists works.. at their request, then according to the same method used for PlayForSure compliancy, and subsequently then decrypted copies of them to make them DRM-free to represent how, if you had the legit means to do so where decrypt means removing the DRM the proper way.. not by decode and transcode). The immediate conclusion i came to, with this transfers rejected instances, was maybe the headers were being misinterpreted in some ways (as the headers may have still contained traces of the former content when protected) and SS subsequently refusing to allow them (but why 4, in one transfer instance.. then 10 in another, in isolation). Now i know there is no technical reason associated with the fact they are DRM-removed/demuxed, as they are (if i send them to players with zero DRM support) handled and transferred ok and 100% - just SS is having a funny five minutes now and them over them. But that potential 'getting confused' prospect got blown outa the window when i subsequently re-tried to send the offending rejected items to the A3000 from the library. Then, when i sent each one at a time, they sent and transferred Ok/Fine/'Houston We Are Go' Could this be a sign of some weakness in bulk transfers between SS 4.0 and the A series decks, or simply SS 4.0..?? Come to think of it, i recall now that when i once tried a bulk transfer and inline transcode of WMA9-LSL's (auto transcode to ATRAC3Plus) using SS 4.0, it also rejected some as being non-transferrable as though they were copy-protected/rights-restricted.. which they definately were not (again, home produced works., no copy protection on this occasion) when i tried to send the bulk batch (in this case, about 200 files across about 10 albums). I forget how many got rejected as being non-permissable to transcode/transer in-line, but it was way too many that when i retried them individually, worked out ok.. Methinks there maybe a WMA support issue here, in SS 4.0. Hopefully, it wont (if my conclusions pan out to be on the mark) re-occur when 4.1 is around.. I'll await 4.1, with itchy virtual paws and claws, and hopefully end up purring... not wishing an evil and vicious clawing session on whoever did the build Be Cool Always 'Tom Kat'

Dunno if it will help at all but.. Over at one of the MD forums, i forget which, ages ago when there was a new release SS that hadn't been made available for download generally (but was available from the Japanese site), there were instructions on how to extract the content of the installer and how to rebuild it/use the content to make it installable outside of a regionalised Windows install (aka not needing a Japanese copy of Windows). Might be worth nipping over the one of the MD forums... you never know 'Tom Kat'

Well, it was pretty much a signed/sealed/delivered certainty that that would never have passed through an RMA claim Having handled lots of RMA's before, and having a keen eye for dodgy RMA claims (you'd be amazed what some people have tried to BS me with over user-inflicted 'accidental' damage, and were highly offended when i failed to fall for the BS), it's damned easy to spot water-damage without even getting the unit apart Whilst it's the first Sony i have heard of that fell into a toilet bowl, it's not the first DAP mind i have come across. Actually, items getting water damaged that way is not unusual - in fact, according to one of my friends in the insurance game, it's one of the greatest circumstances that covers why a lot of water-damaged cellular phones get claimed for Yep, definately these are covered by 'act of god' and user-incompentency clauses protection clauses when it comes to warranty and accidental damage cover Mind you, if you think water damage is gried, try opening up phones and stuff that's been a victim of the old cat urine Cat Urine... about two steps short of HydroChloric Acid for it's damage potential.. and it stinks the room out - that's why if i have to try to repair a CU damaged phone or kit, i open it up and leave it out in the fresh air (in a box, away from the elements) in the back yard for a few hours.. then, if it aint obviously an electrical writeoff, i might waste some hours trying to repair. Mind you, that said, it's almost a certainty that CU has done irrepairable damage. Claws are the cat's no.1 hidden weapon, but everyone forgets the urine.. no.2 hideous hidden weapon Be Cool Always 'Tom Cat'

Apologies in advance, for doing the uncool virtual cat bit and dipping a paw into the topic. Sorry to hear about the issues some are suffering re legally purchased content. I can easily see why people get frustrated when such probs as mentioned happen and they cannot get their legit-purchased/obtained (after all - not all legit stuff is bought, some are promo copies etc or even license-free distributions direct from the artists etc) - and it's gotta be a major kick in the teeth to find you cannot re-insert em back into your transferrable library due to the transfer app/manager refusing to allow the content back in in a transferable form. Sadly, i have no quick-fix answer to offer here - nothing, anyway, that's gonna avoid lossy decode/transcode anyway. Surely there must be a way, and i'll assume the copy-protected content in question is Connect Store downloads, of regaining the licenses sufficiently to get SS to recognise the tracks as legit transferrable content. After all, if you could relicense (for free of course), and get SS to recognise the content as legit.. then other alternative stuff (Gym etc) could manage to accept the stuff too (potentially). Whilst when i work with WMA's, i do use DRM protection (have got legit means to deprotected and re-protected losslessly content i deal with when i produce the content for people), when it comes to producing ATRAC audio, i soon realised it was gonna be a bloody nightmare re DRM to copy protect the resulting ATRAC audio - so not being in the mood or having time to waste fretting about shoddy handling of protected content, i religiously avoid copy-protecting ATRAC content. Sadly, copy-protection also screws u up when it comes to drag-n-drop rapid backup of content from the UMS accessible ATRAC decks - which is why when i posted the quick how-to for rapid backing up, i only qualified it as being suitable for non copy-protected stuff. I sure hope there is a quick and simple non-hacking and non-destructive answer to the recovery process - but i wont hold my breath waiting on the possibility of Sony offering some kinda solution that's practical So all i can say is.. good luck, hopefully someone will find an answer - and for future piece of mind, avoid copy-protecting the content you are gonna send to ATRAC decks, coz life is a lot less stressful when it's DRM free Be Cool Always 'Tom Kat'

Rapidshare (just one of a few public uploader sites) is NOT a good option. For a starter - 'free' downloading is limited to a fixed amount and when you have downloaded x Mb (i forget the actual limit now) you are prevented from downloading via the IP you were downloading via, for an hour or so (the timer used is kinda variable, but it's a min of 1 hour). To get unlimited download access (aka as much as you like, as often and without transfer amount limits) then you need to get a Premiun account. So i would definately not give Rapidshare a vote of approval really on the sheer grounds of the non-Premium users download limitations. Haven't tried any of the other upload/share providers yet, so can't say if any of the others invoke similar limits. However, if you know of one or more other than RS that don't penalise non-subscribers and is equally accessible internationally (some of the sites aint equally transparently accessible regardless of where you are in the world), then this is possible answer. Mind you, you must remember, if using one of those sites to :- 1) Obscure the filenames. 2) Put in an ambigious 'content' reference in where the uploader page asks for some content info. Ok, if you are uploading self-created content or other's work that you have been given the ok to share (aka the creator aint gonna go ape over copyright issues if you share, i mean) - then those two can be pretty much made redundant and forgotten about. But for sure, if you are stupid enough to post files to such sites with clear and obvious filenames that show the content is audio and ties up with copyrighted material that's commericial in origin (aka ripped music) then you can bet safe kit-e-kat funds that the files will disappear rapidly particularly is someone complains etc. I remember someone who posted a lossy-compressed set of audio tracks to RS, and by concidence the names of the files sort of looked pretty similar to some that tied up with commercial music releases.. and some short-sighted idiot naturally assumed he had obscured the names of some illegally distributed audio files. As you can imagine, that friend was pretty much not a happy person when that happened - given that the person he had posted them for was gonna go collected them from RS to go promo the stuff for in the other country. His words, i'll spare you from reading The only real alternative i can think of, outside of P2P and share-sites, where we suffer neither bandwidth issues or stupid limits, is (and bear in mind i would only take this on for self-created content or CCL/PD content ... not for commercial content sharing) to set up a physical library where contributed content can be sent to for central storage, then whoever wants to re-offer localised distribution could then request the required part or whole of the current library. That way, initially, whoever acts as the first point of distro will have their work cut out.. but as people take on parts of that more locally, the workload gets shared. DVD-R, or CD-R, allows (if you keep to say common MD-LP and comparable Hi-MD/ATRAC3Plus ready encodings, aka the ones that are low-medium sized resulting files) for fairly cheap physical distro to get the library distributed to those who wish to act as local library providers. If it was worked on a basis of 'i want xxx, out of yyyy % of the library, i provided the required number of CD-R's/DVD-R's for the purpose and shipping costs' or the modifed version where the receiver then provides blank media in return and bears the shipping costs (aka no charge associated with the content itself), then that can also work. The real best-case, regardless of distro method, would be the concept i outlined somewhere once before - where we aimed to go and be totally legit... so we exploited P2P or other methods to share content - but instead of leeching, the library contributors each donated either x number of commericial releases (either lossless or actual release media) at their cost (aka they buy the original media releases) and what the library (distributed or centralised) would do is fulfil requests at a mere cost of breaking even over the cost of distro media (where used) and any royalty payments to make it really legit (assuming such an agreement could be sorted with the record companies). Maybe that's way too 'uncool' or simply a demonically horrific concept.. to do it legit and play fair - but i was thinking about it at the time on two levels.. 1. General purpose (back when i was an mp3/mp3pro/wma user). 2. A good way to make MD releases (SP or MDLP.. or HiMD in todays terms) available where they aint commercially viable due to low demand (in the eyes of the commericial distributors and record labels) and likewise for pre-cut ATRAC-CD's. After all, if we who put in the time for the good of the ATRAC community do this out of the goodness of our hearts and simply ask no more than to be not out of pocket over the distribution costs and royalty/license payments - both we get something out of it.. those who contribute get something out of it... and those not involved at that level (aka the rest of the world) also get a crack at being able to get pre-cut MD's and ATRAC-CD's not just what few (if any) that do get mainstream official releases. I mean, what a wonderful opportunity to link up the independent artists/performers and all their lovely (often brill quality) works and a market of listeners who ordinarily end up listening to transcoded mp3's etc on their ATRAC-only devices (thinking of MD users there) and simply if you want to fully exploit an ATRAC CD Walkman, then ATRAC CD would be what you would want your purchased pre-cut compressed audio to be supplied in. MDLP rate encodings (pref 105/132k ATRAC3) makes for a good device transparent ATRAC combination. If supplying pre-cut (ATRAC CD's in question), then it really is as simply as fufilling a customer order by making up the ATRAC CD (image it post burn to allow for rapid burning if the same item is requested afterwards by someone else) and posting it. Alternatively, the customer could get it for almost free (no media and shipping cost, just the appropriate license/royalty payments) if they are prepared to download a disk image suitably stored and accessible. MD's, pre-cut, clearly is probably not to everyone's cup of tea particularly for SP cut examples as SP is still a 1x transfer/record process, so you'd really only do them if you had the time and inclination - however, on an exchange basis (blank media + return shipping costs+license/royalty payments in return for the supply of pre-cut MD media) i'm sure the takers on the distro side would increase for MDLP pre-cut would be way more practical timewise. But hey, we can discuss this til the cows come home and still probably get nowhere and still be wandering around in circles. So simply, do what you chose to do.. however you prefer to do it - find some way of informing people discretely what's available and how they can obtain the content.. and see what works. I'd guess most wont want to go to the effort of being totally fair-play and legit - so maybe i'll forget mentioning those kinda aspects in future... after all, a message falling of deaf ears is a wasted effort. 'Tom Kat'

Given that we are in a world of multi-codec devices, and to various degrees, wanting to eek out the max use of the storage and also retain quality... Do not be afraid to mix and match the content... I know in some circles, you will be condemned for practically being a heretic for say mixing a WMA file or three along with mostly mp3's and the odd AAC, or in the case of users of modern ATRAC kit, the odd ATRAC file or three. But who really gives a damn..?? If you were sitting down, from a clean slate, and encoding a purrfect blend of size-friendly and personally happy grade quality audio files to use on your deck, hell why be a slave to one-codec-fits-all attitudes and perceptions/philosophy. If some tracks give the best quality/size combo in AAC vs the other codecs supported, go with AAC for those tracks. Ditto the same consideration for the whole lot, use whatever codec gives the best outcome for a usual instance of the track. And for those who think you are crazy and almost a heretic for being so bohemien in doing so, well.. do as i do.., show em the virtual claws... and remind them it's none of their business And if all else fails, chase em out of your virtual alley... then get back to listening to the good stuff Remember, if it suits you and it's for your purposes, then only your tastes count - when it comes to encoding for other people's listening, then you may have to bow to other people's tastes and tolerences. With the modern ATRAC devices, the only thing you lose with codec mixing, is some of the battery endurance we are used to (bearing in mind that it's based on ATRAC use exclusively, that the massive endurance is gained). But if you are doing the mixing and matching well, to suit a very practical need, you'll find that the scope you have to go for broke with alternative codec choices will give you a pretty near-ATRAC impact on battery endurance, and so redress the balance somewhat. So go with what works, coz that's the virtual cool cat thing to do 'Tom Kat'