marcnet

Nothing... GraphEdit simply just seems to stop processing the .oma and/or writing .wav data... The play icon turns green and the stop icon turns red... You're left with just over a minutes worth of .wav Im only guessing that once the Sony OMA reading filter reaches the end of the .oma file it tells DirectShow to stop processing Furthur more: Ive tried seeking while rendering in GraphEdit... and it seems to suggest that seeking to a place in an .oma will render to the .wav file from that point.

Sorry... I only tested with 2 short tracks ... It seems the maximum wav size is 10.3mb long.... This may be due to the "OpenOmg" source filter being a bit gay with regards to rendering faster than real-time Seems my method needs: a) A c/c++ replacement that can create directshow objects and be able to resume rendering wav files from where it last left off (which will take time, but Im quite capable of doing) a smart-tee filter between the OMG TRANSFORM and the SonyWavWriter. Render the Capture pin (bump) to the Wave/DirectSound device and the preview pin to the SonyWavWriter. This,unfortunatly, is a real-time method.

Go here: http://forums.minidisc.org/viewtopic.php?t=6087

I pre-ordered a mz-nh1 from www.be-direct.co.uk For £189.99 . With free postage. Bargin eh? I didnt know if that price is correct so I phoned to pre-order. They said "Yes. It is correct". They told me mid to end of august as well. Oh, and if the price goes up on their site - they say they wont need me to pay the difference. If it goes down they will refund the difference. Downside is that I live 110 miles from where my card is registered and they will only deleiver to the card registration address. So I payed by cheque to get it delivered to work, when its in stock. And I was gonna buy one in Dixons for £280 .... Good job I didnt eh?

I went into dixons in Newbury today and asked them if they knew anything about "High density minidisc units". I was expecting the answer "what are minidiscs" - it being Dixons and all . Anyway.... I was pleasently suprised. They showed me a leaflet (all shiney and everything) of the upcoming minidisc units. The mz-nh1 (Im after this unit myself) is priced £279.99 exactly. They also had the plasticey 600 model in the shop for sale. I actually held it. Didnt want it though. Too plasticy for my likeing :/ So you might be better off going direct to your dixons shop, as they're cheaper than the online Argos site. Plus there's no postage or anything to pay

I was working on cracking the encryption... but Im not a maths genious. If you can tell me 1) how to crack an encryption algorithm that I have no idea how it works. 2) What keys are used, Are keys used, where the keys are used 3) How to reverse engineer code that has IsDebuggerActive() calls in it. Bareing in mind that this call is made from the return value of GetProcAddress and is not linked directly.

Sure... Just tell me these simple things... 1) How do I crack an encryption algorithm that I have absolutly no information about (apart from the fact that its an encryption algorithm) 2) How do I stop the IsDebuggerPresent() from returning 1 when the Kernel32.dll is loaded dynamically 3) If Uploading is not supported in any way shape or form by the NetMD, how do I add functionality to the MD firmware(s) so that uploading is actually possible. If you can tell me how to do any of these things then ill continue on my quest. But as it stands, im giving up. Ive spent too much time getting nowhere. Ive got other projects on mind now, as well as a fulltime job. Bye.

I believe SP is actually encrypted PCM data - the amount of data being chucked at the netmd in SP mode would suggest so. a) Sony have coded their com objects so that they only decrypt if they're directly connected to a sound device. Ive used graphedit to try other output filters - like a file writer - and it dont work. Im not great at maths, so how would I exactly work out the encryption algorithm from a plain-text file and an encrypted file?

I havent given up yet.. I still have a few tricks to try. Im mainly trying to disable to anti-debugging techniques Sony have put in place. A few guys at work suggested something I havnt tried yet - such as hooking certain Windows API and tricking the Sony software into thinking that there is no debugger running, when in fact there is. If I succeed in this I can see how the encryption system works. muhahahah.....

I should of made this clear (and I belive Im repeating myself, since this is in some other post of mine)... It wouldnt help if you could see the raw USB communication or even if you had a hardware black box that sits between the USB and the MD. This is because the audio data (PCM / Atrac3) is encrypted on the PC, sent to the MD in encrypted form and then the NETMD actually de-crypts the data itself . PS: Ive already hooked into the NETMDAPI dll and seen the commands needed to do all the stuff that the sony software does - ive even managed to send data to the MD. However, since I dont know how the encryption system works the NETMD just ignored the data I sent it due to its decoding/decryption routines not recognising the data I sent. I can rename tracks and do all winmd stuff using raw C/C++ calls to the NetMDAPI.dll though, but Im not releasing any MD software because a) I dont know how the encryption system works WinMD does all the stuff I can do - so whats the point? c) Im busy as Im a slave to the wage

Sony, in their infinite wisdom, decided to only support one operating system (Windoze) - and only support it badly. The transfer of audio between PC and MD is encrypted somehow and Sony software crashes (probably delibrate) whenever it detects a debugger is attached. So there is little hope of a 3rd party developer writing some decent software that allows Windows, Linux and others to use the cool and/or groovy NETMD in a non-sucky way.

Err... forgive me.. but that last post seems to be the most stupid sugestion ive heard unless, of course, there is some magic netmd software that dosnt suck like the sony stuff and does allow true sp transfers. IF such a thing does exist.. .where is it?

Ive said this a million times (well, 3 actually) - but ill write in again First off, if you used the COM interfaces then you would be limited by the restrictions that Sony put in - ie: Only MP3, WAV and CD can be the source media, Files must be converted to Atrac3 before converting to encrypted pcm for SP mode transfer (sucky). Still millions of files scattered over hard-drive (its the API that does this, not the OpenMG software). Check-out restrictions... etc. If you go down to the lower layers (like the netmdapi.dll) then you can transfer and receive data directly to/from the MD - but unless you know how the encryption/decryption system works you can forget this idea. All Atrac3 / PCM data transferred to the MD is encrypted in some mystic way. Oh, and I did say PCM because the API cant encode to the original Atrac format. The API decodes the Atrac3 file and sends encrypted PCM to the MD for it to encode into Atrac1... but anyway.... Now if you tackle (somehow) the second solution, you run into legal problems. The main one being that Sony will not like their (propiratry) encryption system to be cracked. And since Sony is not likely to handout details on how that stuff is done, reverse engineering is the main route to success. Of course, reverse engineering commercial products is kind of illegal.

False. All that happens when you check in files is that the track is DELETED (not uploaded) off the MD and the check-out count is incremented on the omg file.

Im still trying to figure out how the netmd encryption sytem works... I havnt had much time (or luck) recently... After I figure that out (or someone does it for me.... )then Ill release some netmd somewhere that does everything that everyone has been asking for such as more file formats, volume adjusting & normilising, SP encoding (possibly - Ill need a seperate ATRAC 1 encoder to do this....)

I didnt use com spy, or any crappy c++ stuff. I used good fashioned c/asm techniques. 1) D/l a good disassembler - wdasm is good. 2) Look at the function names in the disassembler of the netmdapi.dll file.. they all start with a _ and end in @x - where x is the number of parameters the function takes multiplied by 4. All functions (I assumed) return a 32 bit unsigned integer. 3) In MSDEV (i use MSDEV 6.0 - im not sure if this works with other versions) create a win32 dll - empty project with a standard empty dll main. 5) Create a cpp file and basically create functions with the same names as those in the real netmdapi.dll file. Exclude the _ and the @x part - MSDEV will add these by itself. Make sure you extern "C" the function and make sure its exported. example: there is a function called _NetMDAMSByTrack@4 in netmdapi.dll you should declare the fake function in the fake dll as: extern "C" DWORD EXP NetMDAMSByTrack(DWORD x,DWORD y) the EXP is defined as __declspec(dllexport) - so the function is exported in the dll 6) Oh and you'll need to manually load the netmdusb.dll, netmd.dll and the real netmdapi.dll (rename this so you dont overwrite it with the fake netmdapi.dll) using LoadLibrary 7) and thats it. every function does a GetProcAddress to get the function addr in the real renamed netmdapi.dll and calls it and returns the result - while logging whats going on. 8) Dont do programming in uni/college - I did for 3 years and its crap - learn by experience. - this conversation is for another day.

Ok.. Ive been hacking away at the netmd dlls for a couple of days and ive made a few discoverys about how the shitty openmg program communicates with the netmdapi.dll . I did this by writing a fake netmdapi.dll which logs all calls and parameter values before calling the real netmdapi.dll (which I renamed) Ive managed to write a program that does basic functions (disc renaming, track moving, track deleting, track playing etc) based on the logging information generated by my fake dll, but im stumped on two things before I can get ATRAC data from PC to MD. 1) How does openmg encode the ATRAC data? Which dll's etc are used? 2) The resultant ATRAC file on HD has an 8 byte key which is used for encryption / decryption. This key is then scambled before being sent to the MD. How is this key generated in the first place? And how is the key scrambled? Any help would be appreciated. Especially from sony Once I figure this out I could write a PC->NetMD app that has the following advantages: 1) Dosnt crash as much 2) No random files left over.... Id clean up after myself 3) Possible SP encoding quality on PC 4) More audio format support (ogg for one) 5) Real-time analoge uploading (I know other apps support this.. but it would be nice for an all-in-one solution) 6) Id take other peoples ideas - and may actually implement them.