Hey, so I'm new here. I registered because I need some help, and Lame's SourceForge support page directed me here.
I run a website that allows members to download unlicensed video game music. We don't get many donations, so the server space and data transfers are really taking a toll on my wallet. What I'm trying to do is find all of my mp3 files that were encoded at 320cbr and trans/downcode them to 2-pass v1/v2 vbr (at best quality setting) to save server space (output is generally 190-210). I would batch re-encode my entire collection, but the problem is that more than half of my 60,000+ albums are already at v0-v1 (or at a lower cbr/vbr rate, and I definitely don't want to upcode). I've done over 500 by hand at the slowest speeds for best algorithm matching, and the quality loss is hardly noticeable. Pretty much like cutting the gristle off a steak.
How can I go about transcoding all my 320 cbr to vbr without having to search through all of my albums by hand? Any help will be greatly appreciated!
I would use Foobar and drop all the tracks into a playlist. Then add a "Codec" and "Bitrate" columns into the view which will show you the LAME profile the track was encoded with ("MP3 / VBR V0", "MP3 / CBR" and so on). I would first order this list based on the Codec row and delete everything else except the tracks with CBR encoding. Then order the rest using the bitrate row and discard everything from the list which is encoded below 320kbps CBR. Now you have only the CBR 320kbps tracks which can be transcoded to VBR V1/V2 using the built in converter of Foobar.
With a proper converter setup you can even keep the original folder structure, file names and artwork.
If you are not using Windows i would give Beets (http://beets.radbox.org/) a try which has transcoding capabilities and might allow you to do such complex filtering on the bitrate. Although i haven't tried it yet. There's caudec (http://caudec.outpost.fr/) aswell but i don't know if it supports transcoding based on such filtering either.
If staying with MP3 is not a heavy constraint in your case and would like to lower bandwith usage even more i would suggest you to transcode into AAC (eg. Apple AAC using QAAC -V 63 which yield average ~128kbps). Check out the latest 96kbps AAC listening test here: Result of public AAC Listening test @96kbps (http://listening-tests.hydrogenaudio.org/igorc/aac-96-a/results.html) I would use 128kbps to keep a safety margin for transcoding problems.
I run a website that allows members to download unlicensed video game music.
Why did you feel the need to mention this? By offering advice that might save your site, members and hence the site could be facilitating breach of copyright, something that is forbidden by #9 of the TOS. When it comes to things like this, I never understand why people do not just save themselves the potential headaches by taking a DADT-esque approach. Now I have to puzzle over whether to close this for violating TOS #9 or to leave it open because the workflow-related answers might be useful to other readers in the future.
2-pass ... vbr
I don't think this exists.
2-pass ... vbr
I don't think this exists.
There's no reason it can't be done, but I'm not aware that it has been done for mp3. Some kind of script to call lame iteratively should do the trick.
In what way? Sending a stream through LAME for two passes of the whole lossy encoding process? That is very different from what real two-pass encoding means. The results from the former would be perceptually no better in the absolutely best case, and the entire idea is pointless anyway.
Unless you mean calling the main parts of the encoding algorithm twice whilst analysing the input stream and before writing any new compressed data, but I have no idea whether that is technically feasible.
What I actually had in mind (which might not be what lightrebellion meant) was to encode using lame with a trial -V setting, then see what the average bitrate of the resulting file is. Repeat with higher or lower -V settings until the bitrate is approximately equal to the target bitrate.
This should give you higher overall quality than if you encoded cbr at the target bitrate (but would not give you constant bitrate if that was what you needed for streaming purposes). Think of it as abr that allows greater variability in bitrate but still gives the desired file size.
Ah, OK, basically a ‘manual two-pass’, which could indeed be useful in some cases. However, like you, I’m not sure that was what lightrebellion meant; would many people think of that from the term two-pass? Also, if my interpretation is correct that the desire is for a fast and easy solution, manually checking bitrates and readjusting settings seems too time-consuming. I guess it could be slimmed down by running it on a subset only, in the hope they suggest a representative mean bitrate and hence setting, but the usual caveats about mean bitrates in VBR being of uncertain reliability apply; moreover, games in particular have a wide variety of timbres/styles, making it harder to find a representative subset.
If I recall correctly 2 pass only really makes sense for ABR encoding. VBR encodes are targeting a quality not a bitrate and can assign arbitrary bitrates for chunks within the constraints of the format.
That much is well known (read: has been discussed to death). The question here is whether a manual two-pass strategy with associated checking of bitrates and adjustment of settings could bring VBR specifically, variable as it obviously is, nonetheless closer to a desired bitrate. The answer is: yes, probably, but that entails a question of its own: is it worth the time and effort when, as you pointed out again, a target bitrate is not, or is contrary to, the purpose of VBR to begin with. At least two-pass VBR in its normal, automated incarnation does not place that labour upon the user.