Guys, is there a way to find out if --xlevel has been used on an encode? If it's not used, how will that affect any subsequent use of replaygain on the file?
Also, what's the best way to go about transcoding to Ogg (i want to do -q1 encoding for PDA use). Decode to wave then re-encode or is there a way to do it directly?
Thanks!
H
Full Version: Detecting whether xlevel is used and Ogg transcode
QUOTE(hudson @ Jan 23 2004, 03:44 PM)
is there a way to do it directly?
foobar2000, dbPowerAMP, Winamp...
Also found this a couple of pages back for ogg transcoding:
http://home.wanadoo.nl/~w.speek/multi.htm
Funny how search didn't turn it up.
H
http://home.wanadoo.nl/~w.speek/multi.htm
Funny how search didn't turn it up.
H
You may also want to try UniversalFront. It's one of the most powerful and feature-rich trans-/encoding pieces of software I've encountered. Webpage
As to the question of whether --xlevel was used: this switch alters the way data is stored within the stream, if I understand correctly. That would make it detectable, assuming any app reports on this. Am I correct?
QUOTE(Kalamity @ Feb 4 2004, 09:05 PM)
As to the question of whether --xlevel was used: this switch alters the way data is stored within the stream, if I understand correctly. That would make it detectable, assuming any app reports on this. Am I correct?
Currently there is no tool to detect xlevel but even if there was I think it's only detectable if the encoder needed to use xlevel coding, xlevel files are not marked. The best thing to do is keep logs of your mpc encodes.
I would think the use of --xlevel, or rather the need for it's having been used, could be determined with some confidence, albeit without guarantee.
The use of --xlevel by the encoder itself does change the data striucture inside the stream, unless someone tells me otherwise. However, even if --xlevel is given at the command line, it is only used when needed. This means encoder clipping is detected. Is encoder clippling detectable after the fact? This point is key for the below to be useful.
The theory:
Our 'xlevelscanner' could tell positively if --xlevel was actually used during the encoding of a file. It could also infer, through detection of encoder clipping, if --xlevel should have been used, but wasn't. Obviously --scale could easily cloud this result pool.
The four likely encoding scenarios could return results as follows:
--xlevel given and used: positively detectable
--xlevel not given, but needed: detectable as encoder clipping after the fact
--xlevel given, but not needed: gray area, --scale could have been used
--xlevel not given, but not needed: gray area, --scale could have been used
Something like mpcscan, or as a builtin part of foobar2000 or other decoders, that tells you if using --xlevel did not hack it and to go ahead with --scale(value).
Or is this just chock full of logical falacies?
The use of --xlevel by the encoder itself does change the data striucture inside the stream, unless someone tells me otherwise. However, even if --xlevel is given at the command line, it is only used when needed. This means encoder clipping is detected. Is encoder clippling detectable after the fact? This point is key for the below to be useful.
The theory:
Our 'xlevelscanner' could tell positively if --xlevel was actually used during the encoding of a file. It could also infer, through detection of encoder clipping, if --xlevel should have been used, but wasn't. Obviously --scale could easily cloud this result pool.
The four likely encoding scenarios could return results as follows:
--xlevel given and used: positively detectable
--xlevel not given, but needed: detectable as encoder clipping after the fact
--xlevel given, but not needed: gray area, --scale could have been used
--xlevel not given, but not needed: gray area, --scale could have been used
Something like mpcscan, or as a builtin part of foobar2000 or other decoders, that tells you if using --xlevel did not hack it and to go ahead with --scale(value).
Or is this just chock full of logical falacies?
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.