marcnet

Try converting it to a 44Khz file in any good audio editor and then importing the 44Khz .wav into sonicstage.. When transferring Blue Jam radio show episodes I noticed most of them were at 48Khz samplerate and the audio quality on the MD was terrible.... I converted them to 44Khz in CoolEdit and transferred the resulting .wavs into SonicStage. The result was *much* better.

Well... I was working on the file mapping problem on Monday.... I then got a bit freaked by the SS 2.2 thing and tried to get an alternative working... but as that seems to be a bit of a red herring Ill be going back to fix the file mapping thing. ... Expect 0.08 some time later this week (or early next)

Could you lot please: Try himdrenderer 0.07 with sonicstage 2.2 with the logging option turned on. If himdrenderer fails then please let me know what himdrender said in both the error message box and by supplying the last 5-10 lines of the log file. Meanwhile im working on a fix that does not use the Sony Wav writer, but instead uses a built in microsoft direct show filter that gives me access to raw samples.

I use Opera myself. Its better than Internet Exploder in my opinion. And when I click on my own Donation link the opera "padlock" icon goes from unlocked to "locked" and states that "TLS V1.0 128bit C4 (1024 RSA/SHA)" as the encryption type. I think that because I use frames to hide the URL IE thinks that the page is still insecure. This is sort of true because the host of the frames (my site) is still insecure, but the content of the main frame (paypal) is secure. Try manually going to this link and then pressing the donate button. This will ensure that there are no frames and IE should show the padlock icon correctly. http://www.marcnetsystem.co.uk/cgi-bin/mn2...92133?drs=,90,2, Alternativly go to www.paypal.com and donate that way.

Donation page is secure. My page simply links to paypal. When you go to the paypal page the very first thing you see is: Payment Details ----- Secure Transaction 2) Which brick wall are you talking about? Version 0.07 now renders .oma -> .wav with very little problems

I wonder if SS2.2 trashes uploads... Currently this is the biggest complaint about my method of uploading to .wav, and it isnt anything to with my himdrenderer program...

Nothing is wrong.... Ive been trying out the Intel compiler version 8.0... And i accidently built the latest build with it. Re-get version 0.07 from my site. The .zip file you should get now is 95,417 bytes long, as opposed to the accidently Intel compiled one, which is 113,232 byes long. Sorry for that EDIT: Could you also try this version: http://www.marcnetsystem.co.uk/himdrendere...rer007intel.zip this has been built using the Intel compiler, but without the need for the libguide40.dll (its statically linked instead of dynamically linked)

okay. Version 0.07 is back up. Thanks for your positive comments too... they keep me going :smile:

I appologise for the stupid size of this thread. But anyway it seems like only yesterday I released 0.06... and here we go again. Version 0.07: http://www.marcnetsystem.co.uk/himdrenderer007.zip * GUI version has a batch mode. It might be a bit flakey, so be nice to it. Simply press the "Batch mode" button to access it. It's also why the GUI options has that "all the way over there" feel. * Re-wrote the smoother code in 0.06. It was horrible and had a sample corruption bug in there. Come on, it was gone midnight when I wrote it * There are 2 new options. The smoother analysis window (-a in command-line version) is used to calculate what is a spike and what isnt and the smoother averaging window (-g in command-line version) is a smaller window where the actual smoothing is done. * Added seperate enable/disable option for smoother. The -m option has been modified to simply to this for the command-line version By the way... Is it just me or has my program gained a more "Its good, but we dont need it" feel..... Just seems things have gone quiet on the himdrenderer reaction front....

That is correct. The Win version uses exactly the same code as the DOS version. The only difference is that the Win version has a clickable interface and the DOS version displays an "Open File" dialog Both versions even use the same code to display the "Open file" dialog (the Win version does it when "Browse" is pressed) Hope that clears things up :smile:

Version 006.... * Fixes a small GUI bug where multiple instances of save window / open window could be displayed * Added smoother option to smooth between block borders. This *should* remove clicks .... at least it did on my test file . Use -m to turn off in command-line version. http://www.marcnetsystem.co.uk/himdrenderer006.zip

It's ok ... I can do that myself.... but its a good idea... ill hook up Buzz (http://www.buzzmachines.com/ - which I use for music making) to make simple sine wave / saw wave/ etc sounds to my HI-MD via my sound cards optical out. I can also have Buzz render the same sounds direct to a .wav so I have something to compare with.

I dont have direct access to sonys wav writer fitler - so I cant pump in a known sequence of zeros, or whatever, in the .oma -> temp .wav stage. And the accuracy of DirectShow is not perfect (its quite rubbish when dealing with compressed file)... so I dont exactly know where the repeated audio is - hence I have to search.

1) Direct show (the thing I use to do the .oma to temporarry .wav) has the annoying limit of 1 minute (or less) .wav files. Even if you try to render a 2 minute track in one go you will only get the first minute of audio in .wav form. I got around this limit by processing blocks of x seconds of audio instead of just processing the whole track in one go. Thats kinda one of the main reasons for my program to exist..... 2a) If you simply render x seconds to a .wav file, stop and resume rendering another x seconds you will get missing bits of audio in the .wav. This is bad. 2b) If you render x seconds to a .wav file, stop, seek back y seconds (the overlap time) and resume you will get repeated bits of audio in the .wav. This is not so bad. You can then erase repeated blocks of audio by looking at cetain parts of the .wav (every x seconds - the blocksize ) and finding equal (or near enough) values furthur on. Once the end of the repeat is found ... look for the beginning... Then cut (or rewrite the .wav and miss the repeated bits out) My program simply does 2b. No crossfading. Simple :smile: 3) It might be difficult to cut "where the start & end cross zero" because sample data (a) and its repeat ( may do this.... a) 20 -75 -195 -100 30 -50 50 100 75 ... b) 22 -73 -194 -102 30 -51 49 101 76 ... [/code] Its the way the .oma decompression works.... the PCM values at the end of one block will not be exact to the repeated values at the beginning of the next block. And, as by my example, you can see that there is no zero byte to do the cutting at. Ive got 2 things to try: 1) Smooth the transition from the start and end of the cut by either repeating or averaging values. 2) I could be talking bollocks and I could try cutting at equal or simular values instead of doing a dumb "repeat is here... so cut"

.oma / .omg files also encrypted (including PCM oma files) ... And noone knows how to decrypt them without using Sony's software

Yes. Another version. No core changes, i'm afraid, but there is a reason for this release.... There are now 2 executables. One of them (himdrender.exe) is the standard command-line program. The only change to this version is the version number itself The other executable (himdrenderwin.exe) is the gui version of the same program. The core is IDENTICAL (the same source file) between the command-line and gui versions. http://www.marcnetsystem.co.uk/himdrenderer005.zip As for the click... I still cannot replicate it :/ If someone can experiment more with the overlap & block size settings. This will (hopefully) give me a better idea of what's going on Alternativly look at the source yourself and figure it out ...

The HMA data does contain raw .oma data. Get an "optimized" .oma file and copy it to somewhere else on your harddrive. Then use sonicstage to copy the optimized file to your hi-md. Compare the HMD data with the *copy* of the .oma file you made. The only thing missing is the encryption key.

I knew that -e option would come in handy :smile: As for the "click" problem - ill look into it, even though I have not had the problem during my tests. And yes, sound files are being treated as data. There is no actual recording going on in my program. Its all decoding and data manipulation. What type of ATRAC (HI-SP? LP2? PCM?) are you using when you hear the clicks in the .wav? And coming up in version 0.05: An actual window-based program instead of console based :smile: . It may also have a batch mode too. Sorry TRudolphi, but as I now have the core working quite well Im gonna add more GUI stuff.

Basically as well as outputtin to the sony wav writer I also output to DirectSound. I do this because I found that rendering to sony wav without any kind of clock signal provides less accuracy when seeking in the .oma file. Direct sound provides a reference clock to syncronise the other DirectShow filters (like the oma source, omg transform etc). As far as I know, the sony wav writer does not provide a reference clock that I can use. Hmm.. A bit technical and a bit long. Short answer: Yes it is supposed to happen.

Download: http://www.marcnetsystem.co.uk/himdrenderer004.zip Changelog: * Removed -r option and removed truncation feature. It was rubbish, evil and did bad things. * Wav header should be defintly actually really probably fixed now. Windows Media Player (sik) should no long winge about the file being corrupt at the end * Maybe actually probally slightly hopefully fixed the "repeated audio at end" bug now. The fact this wasn't working in 0.03 is probably down to the rubbish truncation thing mentioned above * Changed title of program to "make it sound less dodgy"

I thought I fixed that too :/

Yes. The new wav is placed in the same folder as the .oma. It is also given the same name as the .oma. Example: If you selected c:audiomdhimdtune.oma then he output will be called c:audiomdhimdtune.oma.wav

Darn... I thought I fixed that.... Ill give it another try tonight. Sorry.

Ive released version 0.03 that *SHOULD* fix both problems. Give it a go and let me know (hey, that ryhmes) http://www.marcnetsystem.co.uk/himdrenderer003.zip

New version 0.03. Download: http://www.marcnetsystem.co.uk/himdrenderer003.zip Changelog: * Resultant .wav Files *should* be truncated to their correct length now (use -r option to turn this off) . * There should also be no repeated audio at the end of files. * New -e option to make program not wait for a keypress when it has finished processing. * If a repeated chunk of audio is detected but it is larger than the maximum allowed then a length of audio calculated from the average repeated audio size will be used. The old behaviour was to ignore these large repeated chunks. Use the -l option to do the old behaviour in these cases. * If you run the program without specifiing an input file on the command line then a nice window will be displayed to allow you to select an .oma file. This is useful for people who can't use the command line and just want to run my program directly from explorer. * Added -s option to allow an optional "seek" value. This value is the amount of time (in milliseconds) to go seek back when the end of a block has been reached. This is in case you wish to change the block size value (- and are experiancing missing audio instead of repeated audio. If you are experiancing missing audio then increase the -s value.