<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Extract Audio from Video Files to WAV using Mplayer</title>
	<atom:link href="http://savvyadmin.com/extract-audio-from-video-files-to-wav-using-mplayer/feed/" rel="self" type="application/rss+xml" />
	<link>http://savvyadmin.com/extract-audio-from-video-files-to-wav-using-mplayer/</link>
	<description>For savvy admins everywhere...</description>
	<lastBuildDate>Wed, 14 Jul 2010 15:57:06 -0700</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: gmendoza</title>
		<link>http://savvyadmin.com/extract-audio-from-video-files-to-wav-using-mplayer/comment-page-1/#comment-494</link>
		<dc:creator>gmendoza</dc:creator>
		<pubDate>Mon, 19 Oct 2009 00:07:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.savvyadmin.com/?p=424#comment-494</guid>
		<description>Agreed!  Your preferred options are well balanced, and produce excellent results, although it&#039;s still a matter of preference either way.  I&#039;ve edited the post to include some of the proposed modifications.

-V 0 and -q 0 result in higher quality at the cost of increased file size.

An audio file at 1.2G was converted to mp3 using both methods.  The higher quality file was 180M, while the other was about 142M.

Using a minimum bitrate (-b 128) typically isn&#039;t a problem when the source doesn&#039;t have many bits below that range.  But as you mentioned, if you are going to use VBR, why limit how low you can go?  It kind of defeats the purpose.

I had actually never used the newer VBR algorithm, so this was nice to learn more about.  For fun, I decided to run a couple tests for comparison in speed.  I noted a slight increase in speed from the old algorithm (5m51.525s) to the new (5m36.424s) using the two different quality settings.  But there was no difference at all when quality settings were identical.  But hey, little things ought to count for something.

I still haven&#039;t found any benefits to removing replay gain computation.  I found the referenced information within the LAME man page interesting.  &lt;a href=&quot;http://www.replaygain.org&quot; rel=&quot;nofollow&quot;&gt;http://www.replaygain.org&lt;/a&gt;  

If anything, I think using --replaygain-accurate seems better for it&#039;s purpose, while disabling I assume can only speed up the process.  Thanks for the comments.</description>
		<content:encoded><![CDATA[<p>Agreed!  Your preferred options are well balanced, and produce excellent results, although it&#8217;s still a matter of preference either way.  I&#8217;ve edited the post to include some of the proposed modifications.</p>
<p>-V 0 and -q 0 result in higher quality at the cost of increased file size.</p>
<p>An audio file at 1.2G was converted to mp3 using both methods.  The higher quality file was 180M, while the other was about 142M.</p>
<p>Using a minimum bitrate (-b 128) typically isn&#8217;t a problem when the source doesn&#8217;t have many bits below that range.  But as you mentioned, if you are going to use VBR, why limit how low you can go?  It kind of defeats the purpose.</p>
<p>I had actually never used the newer VBR algorithm, so this was nice to learn more about.  For fun, I decided to run a couple tests for comparison in speed.  I noted a slight increase in speed from the old algorithm (5m51.525s) to the new (5m36.424s) using the two different quality settings.  But there was no difference at all when quality settings were identical.  But hey, little things ought to count for something.</p>
<p>I still haven&#8217;t found any benefits to removing replay gain computation.  I found the referenced information within the LAME man page interesting.  <a href="http://www.replaygain.org" rel="nofollow">http://www.replaygain.org</a>  </p>
<p>If anything, I think using &#8211;replaygain-accurate seems better for it&#8217;s purpose, while disabling I assume can only speed up the process.  Thanks for the comments.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vyvyan</title>
		<link>http://savvyadmin.com/extract-audio-from-video-files-to-wav-using-mplayer/comment-page-1/#comment-493</link>
		<dc:creator>Vyvyan</dc:creator>
		<pubDate>Sun, 18 Oct 2009 21:15:17 +0000</pubDate>
		<guid isPermaLink="false">http://www.savvyadmin.com/?p=424#comment-493</guid>
		<description>I wonder why would you specify minimum bitrate to be used by using -b 128. It will only waste space with NO quality gain. If you don&#039;t use -b switch whatever is best will be used. That&#039;s the whole point of using vbr which you invoked by -V2. I would also prefer -V0 above -V2 for best vbr results and use --vbr-new to invoke vbr algo.

My command would be:
lame -V 0 -q 0 --vbr-new --noreplaygain audio.wav audio.mp3</description>
		<content:encoded><![CDATA[<p>I wonder why would you specify minimum bitrate to be used by using -b 128. It will only waste space with NO quality gain. If you don&#8217;t use -b switch whatever is best will be used. That&#8217;s the whole point of using vbr which you invoked by -V2. I would also prefer -V0 above -V2 for best vbr results and use &#8211;vbr-new to invoke vbr algo.</p>
<p>My command would be:<br />
lame -V 0 -q 0 &#8211;vbr-new &#8211;noreplaygain audio.wav audio.mp3</p>
]]></content:encoded>
	</item>
</channel>
</rss>
