Andy

I think it might just be that they don't have a nice distributable codec for ATRAC that they can release. Sure, it is lazy of them, but I don't think they have 'blocked' it - it would require a fair bit of work to do.

Instead of supporting individual operating systems, Sony should just make Hi-MD conform to existing specifications fully. The drag and drop of files is step one which they have done. Now they just need to make it so it can play back files which have been put on to it via drag and drop. If they do that, then it will mean that their devices work on all modern operating systems, on the whacky devices (like those routers with built in usb ports) and the software doesn't need to be written by Sony - anyone can write it and make something which works just how they like it. Of course, Sony still thinks that DRM is somehow going to make people buy CDs more, so until some new company comes along and fixes things, we are stuck in this rut.

Yes, this is what I am saying. However, this is not the same as a driver. For example, if you open the command prompt (Start->Run, type "cmd"), then you won't be able to just copy things across like you normally would from the command prompt and have them work. To interface with a device, usually, the chain looks something like this: Device -> Driver -> Shell -> User With SonicStage however, the chain is longer: Device -> Driver -> Shell -> SonicStage -> User With a shell extension: Device -> Driver -> Shell -> User Now, there are a lot of shells around (not so many for windows), but by writing a shell extension, it is specific to a certain shell - so you won't be able to use it from the command prompt. If you had a new driver which managed to do the obfuscation/deobfuscation, then the chain would look identical: Device -> Driver -> Shell -> User But, it would work for every shell which is available (for the operating system the driver works for). However, writing such a driver would be quite difficult (since is would break lots of things having file copying work differently to expected) and not worth the time. What we could always hope for (unlikely, knowing sony) is a different device, such that: Device -> Driver -> Shell -> User Will work because the *device* just works. i.e. the driver is identical to the old one, you can drag and drop any files, and the shell doesn't need any extensions. But the device has some logic in it which says: "If you see an mp3 file, then allow it to be played back". Summary A shell extension will fix most of the problem, but not all, and it still requires far more work than if Sony were to just make hardware that didn't restrict its user. That was a pretty poor explanation, and it isn't actually explaining much so don't worry too much about it.

Just to nitpick, the driver is already available for every operating system and no one would rewrite that. This is talking about a level of abstraction above the driver, so you would need to write a shell extension for whatever shell you are planning to use the device in (e.g. Explorer, KDE, Gnome, Bash etc). But yes, this is good news.

You could implement drag and drop via a shell extension. This would mean that it would work on any computer with the shell extension on it. Hopefully, Sony uses a similar scheme for their Hi-MDs, but there is no guarantee. It really does show you that something is wrong when your own device is obfuscating your own files to prevent you from reading them.

You will probably need one which uses batteries unfortunately. Even transmitting silence over FM takes power, so you need to have some way other than the headphone jack to get power. I think the iTrip uses the proprietory iPod plug thingy to get that power, which is not present on any other device.

Do you want a formal proof? I will happily supply one if so. Otherwise: You have a PCM wave which might be 1000 bits long. You compress it, by your logic, it must now be a less than 1000 bits. This new compressed data can be interpretted as another PCM wave (after all, PCM is just a list of numbers), so you can compress it again and it will get smaller. Repeat lots more times and you will get down to a single number a 0 or a 1. Now, do you think you will have a good chance of decompressing a 0 or a 1 and getting back your 4 minute song? What if instead of getting smaller the signal stays the same size? If this is worrying you, then look up the pigeonhole principle and have a read, it is a fairly simple idea but also quite cool This is a fairly theoretical result, and you will rarely encounter something which gets larger after 'compression' (recording static from the radio, or possibly something with lots of cymbals might do it) so you don't really need to worry about it. But to go through uni doing computer science and all its related maths courses to be told that you can do the impossible is a bit rich Oh - and comparing with zip is quite valid. You can compress audio with a zip just as you can compress text using FLAC. Zip is a general purpose encoder so that is trivial. To compress text with an audio codec (must be lossless) you just create a wav file with a header which says how long the text is (in bytes) and make up a sample rate, give the bit depth a value of 8 and then put the text after it. Although it probably won't compete with zip, it will still compress the text (and in a way that you can decompress it later, which is kind of important )

Worst case, the lossless compression will be larger, though it might only be bigger by 1-bit, so it is such a small margin that it doesn't really matter. Try zipping up a zip file, and unless the zip had lots of small files in it (the file names aren't compressed) then it will end up slightly larger - but not hugely larger, so it is still a good thing. When it comes to music, the compression is far better than worst case.

On the hardware level, I'd like the player to be able to play back audio files which have been copied across without any involvement by Sonic Stage. It is definitely a hardware change, and it means that there is less software required (always a good thing, and I'm a software developer) Other cool things which aren't going to happen, but are cool anyway, and if someone reads this and is building an MD player (or some other type of player) then hopefully they will steal some of the ideas : - Built in non-volatile memory the same size as a disc - when playing back it will cache the contents of the disc to this, so it will never read the same spot on a disc twice (until it is ejected) -> ultra fast startup times, could allow you to continue recording while switching discs and lots of other cool things which I can't even think of. - Double headphone jacks - that is one thing I love about my MZ-R70. What would make it cooler would be independant volume controls. - Battery packs (I haven't heard these mentioned for any 2nd gen units) - Built in microphone - sure it will be crappy, but it will be better than using headphones - note that this is probably not done because of the engine noise, however the non-volatile memory would solve this (no need to have engine running while recording) - Touch screen - Various useful apps like calculator, calendar (with summaries viewable over the remote control even if it is only 1 line), notepad (combined with touch screen, just make it so you can write stuff and it will save it). Some of these things are pretty useful, and wouldn't want to depend on the disc that is in there, which means that there should probably be more non-volatile memory - SIM card slot + built in speaker - Toothpick and tweezers

Or better yet, don't just mimick itunes - but remove all restrictions. Itunes is the market leader right now, and it will take more than imitation to beat them. Doing something similar to itunes except with bigger numbers (i.e. you can backup to more devices or whatever) will mean that Apple can easily fight back by just matching your numbers or going one better. You need to throw a cat amongst the pigeons and get rid of all the crap which people don't want (and in the long term, the producers don't want either).

I should probably point out that I don't necessarily think that the guy before was an idiot or anything else, I don't know any of these people, and the word "idiot" was probably not the best word to describe what I was hoping this guy isn't . Basically, I hope that there will be some positive changes to the way Sony is run because of the change.

To elaborate on an earlier point by someone else: With lossless encoding, you don't know how much space it will take up on disc in advance, this means that you can't say exactly how much time is left. This doesn't mean that the situation is hopeless and the idea should be scrapped - lossless codecs have (or should have, if they are designed with sanity in mind) a mode which says "I can't compress this very well at all, and if I try, then it will end up larger than what I started with, so this next section is just raw PCM data" - which means that the worst case (recording random noise), the space taken up is just a touch bigger than it would be as PCM (you have to account for the space taken by the message). It would be possible to use this figure as a "recording time remaining", however, the time remaining would usually be decreasing at a rate slower than 1s per second which might look weird . If Sony want to make MD an option for everyone, they should support all existing MD formats, MP3 (and VBR mp3), AAC, WMP, OGG, FLAC, WAV, AIFF, and any more that you can think of - if you can think of a format that they don't support, then why should you jump through hoops to get it to play back? They just need to do the work to support it a single time (before manufacturing the player), yet if they don't, then every time you need to play something in one of those formats, then you have to do something extra. More work first saves so much work later. The other equally good option is that sony opens up the firmware and gives good documentation, so instead of them doing the work, the people who want to do neato tricks with their players can do it - and share it with everyone else who might not be so technical.

(extra emphasis by me) Why can't they just make it compatible with both? Oh wait - that is what they are doing. What is the actual problem? As long as they make a reasonable user interface, the people using it shouldn't have to care about what formats they decide to use, they should just be able to put their music onto a disc, without caring about what format (within reason obviously) and it works. It really isn't a difficult concept, and implementation-wise, it shouldn't be too hard either - it wouldn't be innovative, because it is done by nearly every other player on the market. Hopefully the new guy isn't an idiot.

Seconded - with this bit of clarification: will drag and drop work (not necessarily supported - just working is fine) on other operating systems like Mac and Linux?

My understanding of the Hi-MD discs is that to read them, they need to be written to (since writing is more accurate than reading, there are two "window" layers above the data layer which are written to in order to focus on the data below), although it is likely that this is just a poor description coming from the marketting, it makes me think that a player-only unit will still have all the same components as a recorder - and I wouldn't be surprised if the battery life isn't so impressive too.

Still, it doesn't prevent you from transferring stuff - just rename the file (changing the extension) or zip it up. On the other hand, it isn't like the current DRM does anything to prevent this (you could put MP3s on a Hi-MD disc in MP3 format and transfer them to another device. Just thinking about it makes me wonder what the actual point of the DRM is. Assuming that your idea is technically and executively feasible (I think it is a good idea) - it is quite likely that the chip which handles the UMASS stuff is just a mass produced thing which might not even be made by Sony, as a result, they can't easily modify it to go crappy. I think my stance on the whole issue is that we should be pushing for DRM free players, and not accepting any comprimises - there is no way to do DRM so that it doesn't limit some of the rights you already have ("why can't I upload this public domain recording?").

Unfortunately, the DRM needs to identify the computer, and I don't think that you can do that by using UMASS. What would be possible would be a program which runs which simply identifies the computer to the MD, then MD can then restrict your rights by preventing you from copying stuff from one computer to another. In any case, it would be either too restrictive (use as a backup device, your computer explodes, can't restore anything from backup even stuff that isn't music) or too easy to crack (zip your music files, put them on the device, copy to anywhere)

Personally I think the front panel has too much stuff on it. It is probably quite nice to use (nothing worse than really small unusable buttons), but it seems that this thing has too many buttons. Having the recording mode button on the left of the unit and the recording buttons on the right is a bit strange I think, and I'm also pretty used to the track skip buttons being closer to the play/pause/stop buttons. Hopefully more companies will start making their own Hi-MD stuff - if only someone went rogue and made one which could play back mp3s, oggs, wavs or whatever just straight off the disk.... Anyway, I don't think it is bad, in fact I think it is quite good - but I think they could still dial up the awesome on it

If you are doing a pure digital transfer (using the optical cable, or via himd renderer) then the amp won't be used at all (a good thing).

This is correct. Recently, people have been playing around with wavelets for this sort of stuff (while fourier transforms transform into sine waves of differing phases and amplitudes, wavelets are used to transform into any set of functions, by choosing these functions well you can get much more compressable information). The PCM data is in the time domain (think just a plain waveform showing time vs amplitude), in this case, the energy of the signal is (usually) evenly distributed over the whole time, when you apply a fourier transform, you put the signal in the frequency domain, from here, usually most of the energy is in the lower bands, so it is easier to compress the signal. (Very simplified) Also correct. I believe SACD's system is the same principal as a 1-bit amp (both produce a waveform which just alternates between 2 fixed voltages, this waveform is then filtered to form the output). There are about 3 other methods I can think of for DA conversions, one is a resistor ladder (I think this is the most common method) which uses lots of resistors of the same resistance to form the final signal - convenient because all the resistors can be made with the same process and they won't differ much. I'm not sure if it is used anywhere, but some DA's just have 1 resistor per output voltage. I think there is also a method where you iterate through a few steps where each step you get closer to the desired voltage - I can't remember details, so it might be me making it up - I know there is a similar parallel for AD conversion, so I might be getting mixed up. Also correct, except I think most AD converters use "progressive refinement", which requires them to have a input clock which is faster than the sample rate by a factor the the sample depth.

If only that close up had "MP3" written on it My feature for the day is a big fat chunk of RAM (possibly non-volatile like flash stuff) which is at least 1GB, you can then do quick transfers from computer to the unit, and then without being connected to a computer, the unit will slowly transfer stuff from RAM to the disc. The disc will never need to be read in the same spot twice, and there will generally be lots of cool

I given the cost and size of memory these days, I think a real neato feature would be for someone to put 1GB of RAM into a Hi-MD player. Allow it to do ultra quick uploads into this RAM, and then slowly write it all to disk in the background while you are doing other stuff. It would be a little big tricky to do right (you have to trap the disc in the player while it is being written to), but you could also use it as a nice fat anti-shock (never read the same part of a disc twice )... so much goodness potential

I don't think it should need any special knowledge. If you want to do a quick test, then you can try "Damn Small Linux" (just because the download is only 150MB) and see if that boots. If it does and you want to try something bigger and better, then Knoppix or simplyMEPIS are two which seem to get reasonable reviews. I've got simplyMEPIS running on this computer, but am having sound card issues with it right now, so I'm not using it at the moment. Ubuntu is also shaping up quite nicely and has a liveCD available.

The optimal solution would be to make their hardware so that it can play back any bitrate (within some fixed range - there are minimums for these things and maximums which depend on chip speed) and then have an advanced encoding option both in SonicStage and on the unit itself which lets you select whatever bitrate you want. Alternatively they could fix it up by supporting other formats like MP3, Ogg, AAC, WAV etc and make their hardware capable again but not care about sonic stage.

I was more referring to the fact (or opinion) that more people carry Hi-MD players around with them than there are carrying around CD burners which are UMASS compatible (ie can work without fancy drivers) - I don't think there are any such burners in existance - and most people who are carrying a HiMD disc will also be carrying a player - not the case for CDs.