Jump to content

Andy

Members
  • Posts

    116
  • Joined

  • Last visited

Andy's Achievements

Newbie

Newbie (1/14)

1

Reputation

  1. 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.
  2. Andy

    Hi-MD & Apple OS X

    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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. Andy

    3rd Gen

    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 )
  8. Andy

    3rd Gen

    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.
  9. Andy

    3rd Gen

    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
  10. 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).
  11. 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.
  12. 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.
  13. (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.
  14. 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?
  15. 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.
×
×
  • Create New...