ffmpeg convert errors; files seem ok

[andrew.46]

Hi mc4man,

Is the transcode command for 0.7 (or whatever is available for 8.04) much different than the 1.x one?

Hmmm.... I have a deep suspicion that version 1.x marked something of a break from the older series. So the commandline is probably different and I am not entirely sure when the MPlayer import module was created. Not a big problem for me as I only really started using transcode from version 1 and upwards .

Only mentioning because as I recollect 1.x is a bit of work to build on 8.04 (and I get the feeling Logos needs a bit of a break in that regard

Oops you have caught me out there as I cheated a little to compile transcode 1.1.2. I forget which distro I am using sometimes....

Andrew

[mc4man]

Actually doesn't look to difficult depending on what's enabled.
By default almost nothing is. (and probably half the available options may not be used depending on ones usage.

Edit: built fine with a fair amount enabled, as long as you have a recent ffmpeg and x264

Summary for transcode 1.1.2:
----------------------------------------

core options
----------------------------------------
enable experimental code no
enable deprecated code no
static AV-frame buffering yes
A52 default decoder yes
FFmpeg support yes

ffmpeg libraries
----------------------------------------
libavcodec build 3415554
libavcodec version 52.30.2
libavformat build 3416576
libavformat version 52.34.0

hardware support
----------------------------------------
v4l/v4l2 yes
ALSA yes
OSS yes
bktr no
sunau no

optional module support
----------------------------------------
PV3 no
NuppelVideo no

optional package support
----------------------------------------
IBP (libxio) no
X11 yes
Xv extension yes
Xshm extension yes
Xaw library yes
Xpm library yes

libmpeg2 yes
libpostproc yes
freetype2 yes
lame yes
xvid yes
x264 yes
ogg yes
vorbis yes
theora yes
libdvdread yes
pvm3 no
libdv yes
libquicktime yes
lzo yes
a52 yes
faac yes
libxml2 yes
mjpegtools yes
sdl yes
imagemagick yes
libjpeg yes
bsdav no
iconv yes

Edit:
The default hardy is 1.02, as i remember now things changed after the 1.07 version, when it went to 1.1.x

[logos34]

I already use transcode for ripping dvd audio tracks. Does a great job.

But I'd prefer ffmpeg for straight audio conversion--no piping, commands are succinct, etc. I really like it. But now I'm sad because it's not working like it should.

It shouldn't put out false mp3 errors, or convert to flac when your output file suffix clearly has '.ogg' or one of the options like '-aq' is wrong, etc. The first apparently was supposed to have been fixed by now, and I'm using svn ffmpeg. A number of other apps call ffmpeg to do converting, so I need to sort this out for some peace of mind. I hate not knowing what is happening and why

[logos34]

nope, I guessed wrong--the -b bitate ffmpeg option is giving a different rate than the -aq setting, which seems spot on variable/quality output.

on same random file:

-acodec libvorbis -ab 160k = ~169kbps (Nominal bitrate: 160.000000 kb/s)
-acodec libvorbis -aq 5 = ~153kbps (Nominal bitrate: 160.000000 kb/s)

The -aq option takes (up to a point) the same quality settings numbers for argument as oggenc does, as mc4man suggested, i.e. 1-10 (or is it 12?). But the -b option is NOT producing a CBR file, but rather something like am ABR file (since the rate is always slightly higher than nominal rate)--again, maybe following oggenc:

-b n, --bitrate=n
Sets target bitrate to n (in kb/s). The encoder will attempt to encode at approximately this bitrate. By default, this remains a VBR encoding. See the --managed option to force a managed bitrate encoding at the selected bitrate.

I'm also getting annoying error messages from ffmpeg with ogg output too, like:

$ ogginfo 04\ -\ Vivaldi\ -\ The\ Four\ Seasons\ Winter\ -\ Largo.ogg
Processing file "04 - Vivaldi - The Four Seasons Winter - Largo.ogg"...

Note: Stream 1 has serial number 0, which is legal but may cause problems with some tools.
New logical stream (#1, serial: 00000000): type vorbis
Vorbis headers parsed for stream 1, information follows...
Version: 0
Vendor: AO; aoTuV b5 [20061024] (based on Xiph.Org's libVorbis)
Channels: 2
Rate: 44100

Nominal bitrate: 160.000000 kb/s
Upper bitrate: 4294967.295000 kb/s
Lower bitrate: 4294967.295000 kb/s
User comments section follows...
encoder=Lavc52.29.0
Negative or zero granulepos (0) on vorbis stream outside of headers. This file was created by a buggy encoder
Vorbis stream 1:

...

I'm ignoring them for the time being. can't be right

[logos34]

Does anyone use anything other than -q settings with oggenc?

I use it strictly with quality option...Is it true that for CBR ogg, you have to specify three different parameters:

oggenc --max-bitrate=n --min-bitrate=n bitrate_average=n file.wav

bitrate_average=N
Set the average bitrate for the file to N bits per second. When
used without hard minimum or maximum limits, this option selects
reservoirless Average Bit Rate encoding, where the encoder
attempts to perfectly track a desired bitrate, but imposes no
strict momentary fluctuation limits. When used along with a
minimum or maximum limit, the average bitrate still sets the
average overall bitrate of the file, but will work within the
bounds set by the bit reservoir. When the min, max and average
bitrates are identical, oggenc produces Constant Bit Rate Vorbis
data.

seems like a clumsy line for simple constant rate. I have no need to use it, since I don't stream or anything, just wondering

[mc4man]

I think you could drive yourself nuts with this...

In regards to ffmpeg and it's -aq for the 2 formats in play here (mp3 and vorbis

The -aq seems to work fine and corresponds to the respective quality settings, -V 0-9 for lame and -q 1-10 for vorbis

Sometimes for mp3's the runtime is wrong, other times it's correct, sometimes it's correct in one player, wrong in an other or wrong with different runtimes in different players

Most likely for correct is a source of flac or ogg, most likely for incorrect is any wma and aac, but not always for any of them, a wav source goes either way, with a wav coming from a decompressed lossless following the above most times

The encodes themselves seem to fine in all cases, though lame seems to be the best choice for mp3 if additional options are desired or the runtime is wrong or wrong for chosen player

I haven't seen any of those errors you've posted

[logos34]

I think you could drive yourself nuts with this

LOL, I think I'm already there...


to hell with it, it's not all that important, I can find other ways to convert if need be, just wondering about these error messages and oddities with output format and options...although you're right, the quality setting does correspond to the respective codecs--I guess I was thrown by the initial erroneous bitrate (i.e. '64 k/bits', etc.), and the errors introduced additional uncertainty.