01-22-2009, 03:45 AM
I've read what someone else has said about this topic elsewhere,(transcodes) and I've found it very interesting.
Rather than try to put this into my own words,I'll just quote the topic conversation for anyone who might be interested here.
As a linux user who refuses to use windows apps (even in wine),I have not been able to use Dbpoweramp,which is apparantly a great tool for checking for transcodes.
Quote:
I have used a number of ways to detect whether a file has been transcoded.
First point of reference, is to check the lowpass filter in a prog like adobe audition
a 320 will have information up to 20 khz, a 128 will usually have the cut off at 16 and 192's and most VBR's cut off around 18.6/ 19
Secondly, VBR - 2 rips are usually scene rips so if its a scene rip you can almost guarantee that it hasn't been transcoded otherwise it would have been nuked.
Thirdly, often transcodes wont have gapless information and sometimes wont have the original box checked in the lame header. Also, if a file has a replaygain value then it is likely not transcoded.
I find Dbpoweramp very helpful in detecting transcodes as when installed it integrates into the windows shell so when you drag your mouse over a file it will display lots of information (codec used, bitrate, header details etc) and you can usually gauge an idea whether a file has been transcoded or not.
All of these things are very well, but the only truly 100% way to know if a file has been transcoded is if you have encoded it yourself from the source
|
A question to the poster:
Quote:
|
how can Dbpoweramp be useful in detecting transcoded files , if something was ripped at 192 k and is transcoded to 224k then it will flag up those files as 224k , this happened with the transcoded 192k rip of Black Ice , both the 224 and 320k transcoded versions of Black Ice that are all over the place flagged up as 224 and 320k respectively viz poweramp .
|
Reply from poster:
Quote:
Because it will show that there is no gapless information, that the original tag isnt checked, that their is no lame header etc
I am looking at the same rip with dbpoweramp as I type this and it shows all the information that you would expect a transcode to have.
|
A screenshot of the trancoded files.
A screenshot of an original rip.
Note that this has nothing to do with the bitrate that was selected when the original source was ripped.
It could be 128kbps or 320kbps,that is not the point.
The comparison of the screenshots are to show that the transcodes are NOT gapless,they are NOT tagged original,etc.,where-as an
original rip at even 128kbps WILL be gapless,and WILL have the original tagged checked.
I haven't run across many files yet that do have those credentials in the metadata.
That is all fine and well,but my argument with the above statements would be this.
I never rip directly to .mp3,where-as the crendentials mentioned would be present.
I will rip to .wav,then transcode to lossless Flac.
Then if I did transcode to 320kbps mp3 for whatever reason,the credentials stated above that you would be looking for in Dbpoweramp would not be present.
Because it is NOT the original rip!
But does that make my 320 transcode from a lossless format,that was ripped from the original cd any less in quality than if you ripped directly to 320 .mp3 from the cd?
No.It doesn't.
The transcode from a lossless source is digitally the same as a direct rip.
Lossless is lossless,and that's all there is to that.
The one thing I will agree with completely in the above statements is this.
Quote:
|
the only truly 100% way to know if a file has been transcoded is if you have encoded it yourself from the source
|
If someone is so concerned about the quality of the file,spend the $10-15 and buy the original cd.
I don't want to sound harsh here or anything,but if someone really can't tell if it's a transcode just by listening to it,this is something that one shouldn't even be concerned with.
Looking at some data that says it's an original rip isn't going to make it sound better.
It may look better,but it won't sound better.