Tír Na HiFi

tony wrote:Can someone just list the new files required to try it and does it play all formats or just 16/44?

There is a zip file which contains all the files, shall update it with the latest versions.

grisaia wrote:What does Mqnrewrite do exactly? I can't find this on previous pages

copies selected wav files using optimised code and amount of data in the copy loop in an attempt to improve the sq of the file when it's played. Many people report differences, and it points to noise being stored in some way in the wav file.

sima66 wrote:I love this idea of mqnrewrite!
Very practical and convenient to make a playlist!
But there is still even better if rename the song in the "OUT" folder, just to one letter or number.
The highs and details are much better.

That is something what is worth trying, or maybe include in mqn.

people have also said the root directory makes a difference.

Has anyone tried copying the file to a different folder, does it still sound the same ? Moving a file just changes pointers.

Could have a process where the playlist is written to one file in the root directory ready for playing.

Haven't tried a shortened file name yet to see if it makes a difference.

sbgk wrote:copies selected wav files using optimised code and amount of data in the copy loop in an attempt to improve the sq of the file when it's played. Many people report differences, and it points to noise being stored in some way in the wav file.

Hi Gordon,

stored noise in the bits is something I am trying to verify at the moment as a consequence of ripping results with R2 in GUI, Minimal Server or Core mode. There are reports of better sq if ripped in Core. That points to stored noise in the bits. I am trying to verify if the resulting files can be identified as different for example via CRC, SHA-1 or hashes.

Could anyone identify the files resulting from mqnrewrite as different from the original files?

Any ideas about the right methodology/software approach to measure file differences?

Thanks
Thomas

P.S. I do need to find time for Mqn again.... ;)

I tried to use v13 Haswell rewriter but it comes up with memory error.

Would it be because I use RAMOS and it already is in RAM and rewriter is not optimized for this kind of use?

I used it without batch file tough just rewriter.exe in previously described folder structure and test.wav in same folder.

Cheers

sebna wrote:I tried to use v13 Haswell rewriter but it comes up with memory error.

Would it be because I use RAMOS and it already is in RAM and rewriter is not optimized for this kind of use?

I used it without batch file tough just rewriter.exe in previously described folder structure and test.wav in same folder.

Cheers

Did you follow Gordon instructions how to make those 2 folders?
You don't actually make these folders those commands he posted will
It should be more clearer explanation:)
No to RAMOS got nothing to do with it
Thanks
When you get working prepare yourself:)

sbgk wrote:

sima66 wrote:I love this idea of mqnrewrite!
Very practical and convenient to make a playlist!
But there is still even better if rename the song in the "OUT" folder, just to one letter or number.
The highs and details are much better.

That is something what is worth trying, or maybe include in mqn.

people have also said the root directory makes a difference.

Has anyone tried copying the file to a different folder, does it still sound the same ? Moving a file just changes pointers.

Could have a process where the playlist is written to one file in the root directory ready for playing.

Haven't tried a shortened file name yet to see if it makes a difference.

You meant "cut" not "copying", cause copying will loose the benefits of rewrite?

But, even when cut the file from the folders and paste in the root, it changes only the pointers, but it sounds better!!
Maybe those to many pointers are making that difference?!

Up until using this rewrite I used a PeterT script what did copy/rename the file into the root folder and always sounded better.
Now I don't hear the difference anymore and I'm assuming is because the benefit of the script is lost when "copying" after the rewrite is done.

in order to create a directory called mqnrewrite and out folder (inside mqnrewrite directory)

open a cmd window and run these commands

cd \
md mqnrewrite
cd mqnrewrite
md out

note:this above commands will create 2 directory in drive C
to create in different directory after first command cd\ put letter of your drive choice for example:
cd\ D: enter
D: enter and do rest of the commands above
that will create Mqnrewrite and out folders

close the window

copy mqnrewrite.exe, mqnrewrite.bat,paste.exe to mqnrewrite directory

Octagon wrote:

sbgk wrote:copies selected wav files using optimised code and amount of data in the copy loop in an attempt to improve the sq of the file when it's played. Many people report differences, and it points to noise being stored in some way in the wav file.

Hi Gordon,

stored noise in the bits is something I am trying to verify at the moment as a consequence of ripping results with R2 in GUI, Minimal Server or Core mode. There are reports of better sq if ripped in Core. That points to stored noise in the bits. I am trying to verify if the resulting files can be identified as different for example via CRC, SHA-1 or hashes.

Could anyone identify the files resulting from mqnrewrite as different from the original files?

Any ideas about the right methodology/software approach to measure file differences?

Thanks
Thomas

P.S. I do need to find time for Mqn again.... ;)

Very interesting, but I would like to see some more scientific explanation behind this theory. If that is true, I'm wondering what I would be able to read from this forum, thinking, how many different stages information has to go through before it hits my screen, probably just noise, or noisy letters. How many times pictures, videos, music files, whatever gets copied and transferred through thousands of miles of cables, to satellites back and forth, and I still see the same thing like the person who generated it. It's one thing sending bits in timely manner to the DEC, and moving bits from one media to another media, where you have all kinds of luxury to do checks and comparisons, between source and target version. Don't we have transmission protocols developed to do check-sums and all other tricks to make sure that information gets transferred from A to B. Is that not beauty of digital information, compared to analog world. Try to remember old analog TV, and compare it to today's TV. I can loose picture on my TV (from satellite), if tick clouds come around during heavy storms, but it will not partially degrade, like we remember old analog TV.
If one bit in a byte is not right, information is different, so how is that noise stored in that particular byte, I would like to see explanation? I probably missed some classes during my schooling.

Octagon wrote:

sbgk wrote:copies selected wav files using optimised code and amount of data in the copy loop in an attempt to improve the sq of the file when it's played. Many people report differences, and it points to noise being stored in some way in the wav file.

Hi Gordon,

stored noise in the bits is something I am trying to verify at the moment as a consequence of ripping results with R2 in GUI, Minimal Server or Core mode. There are reports of better sq if ripped in Core. That points to stored noise in the bits. I am trying to verify if the resulting files can be identified as different for example via CRC, SHA-1 or hashes.

Could anyone identify the files resulting from mqnrewrite as different from the original files?

Any ideas about the right methodology/software approach to measure file differences?

Thanks
Thomas


P.S. I do need to find time for Mqn again.... ;)

Thomas, would that CRC or SHA (no idea what they mean) change when you copy the song from one place to another?
I'm assuming NOT, but the sounds degrades with every single copy!
Maybe that will be your answer.