• Welcome to ASR. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Phono Cartridge Response Measurement Script

I'll try to figure it all out thank you.
;-)
to be honnete with an old mm , better than -40db to 1k without this electronic stage, this one necessarily paying on other points ...
I don't really feel interested in this approach.
;-)
Sure, there are carts that do 40dB+ without any assistance. The thing is, I'm not particularly wealthy so I'll just buy the best I can afford and then tweak the hell out of it :cool:
 
Maybe show this to JP privately before posting something named REV16.4 and confusing the hell out of everyone? It seems disrespectful to go about this this way.
I see your point but I also agree that the script could use some documentation/clarification/comments in the code. I'm somewhat ashamed to say that I needed to have ChatGPT expain it to me :facepalm:
 
I see your point but I also agree that the script could use some documentation/clarification/comments in the code. I'm somewhat ashamed to say that I needed to have ChatGPT expain it to me :facepalm:
I too have made such notes on the script and have even shown them to JP. He's aware and it's his call as to how it unfolds. I agree that it's something to discuss. But this was a completely rude way of doing it.
 
Maybe show this to JP privately before posting something named REV16.4 and confusing the hell out of everyone? It seems disrespectful to go about this this way.
@USER -- Obviously, you do not code. This (what I have done in reformatting and making it (the script) more legible, at least to someone who uses python "every day") is high praise, and never disrespectful. But -- in truth -- the code belongs on github, with full attribution [to both Scott and John] , and with the ability to clone and check-out. I think my suggestions will prove salient and beneficial to John [JP] -- but, if an admin tells me to pull it down, I will happily remove it. Same code, very sight changes, and now (partially) documented.
 
Last edited:
@USER -- Obviously, you do not code. This (what I have done in reformatting and making it (the script) more legible, at least to someone uses python "every day") is high praise, and never disrespectful. But -- in truth -- the code belongs on github, with full attribution [to both Scott and John] , and with the ability to clone and check-out. I think my suggestions will prove salient and beneficial to John [JL] -- but, if an admin tells me to pull it down, I will happily remove it. Same code, very sight changes, and now documented.
It is very clear as to what you are doing, don't be smug. Having this on github has been discussed and people know what would have to change. I'm not saying that your changes aren't helpful, I'm saying that you should have the decency of either bringing up the subject first or talking to him privately. I can't imagine any serious or professional coder jumping in out of nowhere and offering something as someone else's latest release.
 
It is very clear as to what you are doing, don't be smug. Having this on github has been discussed and people know what would have to change. I'm not saying that your changes aren't helpful, I'm saying that you should have the decency of either bringing up the subject first or talking to him privately. I can't imagine any serious or professional coder jumping in out of nowhere and offering something as someone else's latest release.
Yes -- it is very clear that I am attempting to improve the code. Whatever your 'moral compass' is telling you, that fact remains. I cannot speak to your imagination, or your ideas of professional conduct.
 
There are some issues that need clarification: Under what license (read: terms and conditions) did Scott Wurcer publish the original version of this script? What license would @JP like to use for his additions to the script (bearing in mind that his licensing would have to be compatible with what licence Mr. Wurcer used for his original work)?

Software development, especially when done in the open, is rife with "idea guys" that are quick to list their demands - things they think the developer should do - but are not willing to do the actual work themselves. I've been guilty of this before. My development skills are, let's just say, not so good.

In open source development, it's generally seen as very good manners to not just criticise the work of others but instead to actually do the hard work and offer your ideas and improvements as working code. Just like @JP did - he didn't bug Scott Wurcer with his wishlist, he improved the code.

Granted, you can criticise @cport101 for bumping the version number, but all in all, he doesn't come here stating his demands, he actually does the work and puts it up for discussion. I doubt that anyone mistook his refactoring for a new version from JP.

In the end, it all comes down to licensing. IANAL but I have spent a lot of time around software developers both professionally and privately (being a sysadmin by trade) to know the implications and problems that the topic brings. Maybe we should take this opportunity to clarify the intentions (T&Cs as defined in a software license) of those doing the original work and the derivatives.
 
Looking at the JP tests using STR-100 type 3 new there are some similarities but my measurements seem a little more extreme. I did play with Azimuth and got the channels much more balanced when it comes to cross talk even if they are not as low was would be expected. Now I am wondering if I am driving blind with the STR 100 when it comes to azimuth.... seems like it unfortunately.

The 1kHz reference tracks on the current Ortofon record are pretty good. The don't all agreed so it's pick your poison, but go with something that can show ~-35dB. I know someone who uses UTR and say they get good crosstalk valued with that one as well.

Tangentially I got a shipment notification for my PTG/II from CD Japan today. Funny as the second cart I bought circa 2010 was a PTG/II.
 
There are some issues that need clarification: Under what license (read: terms and conditions) did Scott Wurcer publish the original version of this script? What license would @JP like to use for his additions to the script (bearing in mind that his licensing would have to be compatible with what licence Mr. Wurcer used for his original work)?

Software development, especially when done in the open, is rife with "idea guys" that are quick to list their demands - things they think the developer should do - but are not willing to do the actual work themselves. I've been guilty of this before. My development skills are, let's just say, not so good.

In open source development, it's generally seen as very good manners to not just criticise the work of others but instead to actually do the hard work and offer your ideas and improvements as working code. Just like @JP did - he didn't bug Scott Wurcer with his wishlist, he improved the code.

Granted, you can criticise @cport101 for bumping the version number, but all in all, he doesn't come here stating his demands, he actually does the work and puts it up for discussion. I doubt that anyone mistook his refactoring for a new version from JP.

In the end, it all comes down to licensing. IANAL but I have spent a lot of time around software developers both professionally and privately (being a sysadmin by trade) to know the implications and problems that the topic brings. Maybe we should take this opportunity to clarify the intentions (T&Cs as defined in a software license) of those doing the original work and the derivatives.
@arendj Just for reference, any changes you make to [any] code *must* be referenced in a *new* release/version number -- if you want to be "ethical." So I take umbrage to the low-brow critique that I was doing something wrong by incrementing the revision scheme to include my changes. On the license -- the cat (and code -- with no license) are "out of the bag", and have been published on a public web site. Trying to exert (post forum publication) more than GNU/BSD or (my preference) MIT licenses at this stage will be "interesting" - MIT is the most liberal of all the "open-source" code licenses.
 
Last edited:
@arendj Just for reference, any changes you make to [any] code *must* be referenced in a *new* release number -- if you want to be "ethical." On the license -- the cat (and code -- with no license) are "out of the bag", and have been published on a public web site. Trying to exert (post forum publication) more than GNU/BSD or (my preference) MIT licenses at this stage will be "interesting" - MIT is the most liberal of all the "open-source" code licenses.
Changing the version number when changing the (published) code is - ethics aside - just a practical neccessity. The issue arises when the project does not have a name. If it were called "Scott's-script-modified-by-JP-version-1.0" and you'd change it, you'd probably call it "Scott's-script-modified-by-JP-and-cport101-version-1.0" and everything would be hunky dory.

As I've said before, this thing should have a name.

About taking published code without a license attached and modifying it: It all depends on your jurisrisdiction. I'm in Germany where courts are known to be weird and sometimes clueless. You're most probably fine most of the time, if you like taking chances.

Then again, I'm a nerd and I like certainty and clarity :)
 
I think we can use dicts {} and lists []

I don't know that I'm happy with how the functions are laid out presently. It was an initial stab and a lot of functionality has been added since with more to come, and the current lists are a bit unwieldy. It is a balance of tightening it up and keeping it easy to hack as I do use it in a lot of different ways, some of which I hope to incorporate.

I'm also reminded of my uC C code for my MN6042 replacement. The code for that is about 1/4 the number of lines from when I first had it working, and when I do need to tweak something every a few years it's the original code I have to refer to in order to get my bearings.

This is also a learning experience for me - this script is the totality of my experience with Python.
 
I see your point but I also agree that the script could use some documentation/clarification/comments in the code. I'm somewhat ashamed to say that I needed to have ChatGPT expain it to me :facepalm:

Cheater! :p

I'm working on an expanded version of this post that more throughly explains how it works and why it's needed. This is what reserved post #2 in this thread was aways intended for.

In the end, it all comes down to licensing. IANAL but I have spent a lot of time around software developers both professionally and privately (being a sysadmin by trade) to know the implications and problems that the topic brings. Maybe we should take this opportunity to clarify the intentions (T&Cs as defined in a software license) of those doing the original work and the derivatives.

Scott's always been consistent everything he has posted is public domain. When I re-confirmed this by asking if I could post the script here in '21, his response was "No problem ever, I place everything I do into the public domain." And since the heart of the script is his work, forever that shall be.
 
I don't know that I'm happy with how the functions are laid out presently. It was an initial stab and a lot of functionality has been added since with more to come, and the current lists are a bit unwieldy. It is a balance of tightening it up and keeping it easy to hack as I do use it in a lot of different ways, some of which I hope to incorporate.

I'm also reminded of my uC C code for my MN6042 replacement. The code for that is about 1/4 the number of lines from when I first had it working, and when I do need to tweak something every a few years it's the original code I have to refer to in order to get my bearings.

This is also a learning experience for me - this script is the totality of my experience with Python.
I totally appreciate the work you're doing. There's never been any effort like this and your work might be filling a bigger gap than you think. You may find graphs made with your scripts in a Hifi magazine one of these days ;-)

Funny that you mention microcontrollers, that's what came to my mind when I read the code and saw all the hardcoded values in the script. No offence intended - I couldn't pull this off myself.

Obviously, this script is about the math first and foremost - there are enough people who write great python code, yet no one has yet invested the energy and research to come up with something as slick as this.

Bringing it all into a more 'pythonic' way, if you will, was what I had in mind when I posted my addition of 'argparse' to enable setting variables when executing the script, instead of changing the source for every time it's run.
 
Direct comparison of CA-TRS1007 and Denon XG7001, 1 kHz-20 kHz.
Left and right:
Shure V15VxSASB_140 pF 47 kOhm_CA-TRS1007 vs Denon XG7001 left 2.png
Shure V15VxSASB_140 pF 47 kOhm_CA-TRS1007 vs Denon XG7001 right 2.png

Crosstalk in left is quite different, similar in right. Distortion generally similar but consistently poorer in right channel. Has anyone tested antiskate force vs distortion and channel?
 
@Thomas_A....

I've contemplated a bit - since we've FFTs of the time slices, would a waterfall of those have value in looking at mechanical system performance?
 
Has anyone tested antiskate force vs distortion and channel?
Not yet but it's on my list. I've been keeping mental tabs in some of the patterns I've seen in the distortion spectra.
 
I don't know that I'm happy with how the functions are laid out presently. It was an initial stab and a lot of functionality has been added since with more to come, and the current lists are a bit unwieldy. It is a balance of tightening it up and keeping it easy to hack as I do use it in a lot of different ways, some of which I hope to incorporate.

I'm also reminded of my uC C code for my MN6042 replacement. The code for that is about 1/4 the number of lines from when I first had it working, and when I do need to tweak something every a few years it's the original code I have to refer to in order to get my bearings.

This is also a learning experience for me - this script is the totality of my experience with Python.
Well JP (!) don't let any of that slow you down -- what I did can always be done "after the fact" -- keep going with the ideas and the 'functional code' -- you are making it work, and this is a very good tool for us all. I do lots of "network" programming with python, and (as I have to share it) being able to read it is important in my neck of the woods. I am hoping I can catch up to help with ways to structure and organize the data, and to make the variables PEP compliant and "self_obvious" -- I have not had to look at many "signal analysis" type scripts, so I am learning too. On another note, I thought I had one of the more complete "Test Record" collections [ I used to work with Wally Malewicz of WAM engineering - and we collected quite a few -- the RCA Technical Series are also worth looking at] -- but it sounds like you will exceed me, and I am very curious to hear more about your efforts to have a mastering group "make an accurate one" for you. Back to the script -- I did like the one idea of making an 'argument parser' to be able to toggle the options via cli, and I would suggest incorporating that into a future release. Anyhow -- keep it up -- one (stupid) question -- if you use the TRS-1007 (or one of it's siblings that go to 50 Khz) with RIAA eq, and not the equalization filter they suggest in the linear notes, what are the appropriate setting in the script to null that effect? The treble on the LP is cut "flat". Keep up the good work.
 
Last edited:
Back
Top Bottom