Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Re-encoding, with goal of "preserving quality" (Read 8673 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Re-encoding, with goal of "preserving quality"

Hello everyone. I am sure you people are receiving such questions month after month, however I have done a quick search and have not found exactly what I am looking for, so I thought maybe of opening a new topic and seeing what you guys had to say.

Also please keep in mind that I am not too savvy in this domain. What I am looking to do basically is converting the audio of family-camera videos to CBR, so as to fix some sync issue I have stepped on (c.f. http://forum.doom9.org/showthread.php?p=1412005).

More to the point, my audio files currently are under "22050 Hz, 256 kbps ABR, stereo," and to fix the issue I have stepped on I apparently will have to convert them to "44100 Hz Stereo CBR." I wanted to know the necessary bitrate (kbps) for the preservation of audio quality, with the advantage of avoiding dwelling too much into "overkill."

Put into more succinct a manner, would a choice of 320 kbps, always with the goal of "avoiding potential degradations in audio quality," seem like a sound one?

P.S.: here is a common example (i.e. with "variable" bitrates averaging the one hundred fifties) of audio information outputted from the talked-about videos:

Quote
Audio
ID                              : 1
Format                          : MPEG Audio
Format version                  : Version 2
Format profile                  : Layer 3
Mode                            : Joint stereo
Mode extension                  : MS Stereo
Codec ID                        : 55
Codec ID/Hint                    : MP3
Duration                        : 3mn 38s
Bit rate mode                    : Variable
Bit rate                        : 148 Kbps
Channel(s)                      : 2 channels
Sampling rate                    : 22.05 KHz
Stream size                      : 3.88 MiB (11%)
Alignment                        : Split accross interleaves
Interleave, duration            : 34 ms (1.01 video frame)
Interleave, preload duration    : 859 ms

Thanks,
twipley


 

Re-encoding, with goal of "preserving quality"

Reply #2
Nice, and made me laugh (statistic-course memory uncoverings).

However, is not there a fiddle-free formula lying around somewhere that could be used into determining necessary bitrates?

Re-encoding, with goal of "preserving quality"

Reply #3
Perhaps you could use MP3 repacker or a similar tool to losslessly convert the ABR/VBR to CBR.  It'll be much larger, but no quality loss.  It basically just pads up every frame with 0's, but doesn't re-encode any of the existing audio.

Re-encoding, with goal of "preserving quality"

Reply #4
Quote
It'll be much larger, but no quality loss.


I don't think that 148 -> 160 kbps conversion will make files "much larger".

Re-encoding, with goal of "preserving quality"

Reply #5
Perhaps you could use MP3 repacker or a similar tool to losslessly convert the ABR/VBR to CBR.  It'll be much larger, but no quality loss.  It basically just pads up every frame with 0's, but doesn't re-encode any of the existing audio.

What he is actually looking for is a way to convert 22050 sample rate to 44100 sample rate with minimal quality loss. Once that issue is addressed then we can talk about cbr vs. abr vs. vbr.

One thing to point out here is that when you reencode, be sure to set a lowpass frequency of 11 kHz, because your original files have no content above that.

Re-encoding, with goal of "preserving quality"

Reply #6
ABR/VBR is not supported in AVI files, but if you switch to MKV or MP4, you shouldn't have synchronization problems anymore and you won't have to transcode the audio. Technically, it is possible to use VBR in AVI files, but programs like VirtualDub do not support it since it's not standard. This seems like more of a Doom9 than a Hydrogenaudio question, as A/V desynchronization isn't usually related to the audio file itself.

Re-encoding, with goal of "preserving quality"

Reply #7
Before you start worrying about "audio quality", have you fixed the sync problem?

You no longer have the original A/V file that was (apparently) in-sync?

Re-encoding, with goal of "preserving quality"

Reply #8
You don't need to resample (read the doom9 thread - the OP is only doing it to get a re-encode option in VirtualDub's GUI!).

You don't need to re-encode, since mp3 re-packer can sort it out.

Either use mp3repacker and re-mux to AVI, or just re-mux to MKV as-is.

With a 256kbps 22kHz stereo source, it's unlikely you'll hear much/any difference between 256kbps and 320kbps. One trick you can try: re-encode to VBR -V2, and look what bitrate lame chooses for the various frames - note down what the highest bitrate used is. If there are only a tiny number of frames at that rate, you might choose to use the next highest rate instead. Then go back to the source, and encode CBR at that rate.

Transcoding always loses quality, but I think it's the least of your worries here - 22kHz!

Cheers,
David.

Re-encoding, with goal of "preserving quality"

Reply #9
Quote
With a 256kbps 22kHz stereo source


IIRC max. bitrate for MPEG-2 (22.05 kHz) layer3 is 160 kbps. And, from the 1st post:

Quote
Bit rate : 148 Kbps

Re-encoding, with goal of "preserving quality"

Reply #10
Hey everybody,

I've spent the last hours on this. Currently, two alternatives are in my mind:

1) resampling (to unlock vd's CBR encoding) and CBR reencode using virtualdub, but that would result in audio-quality loss. I believe, so I'd rather:

2) output wav using virtualdub, output mp3 file using lamedrop, then use mp3repacker to "losslessly convert (without re-encoding) the ABR/VBR to CBR [...] without any quality loss," basically just by padding up every frame with 0's, as benski has put it. Then, re-mux audio (coming from mp3repacker) together with video-only AVI (coming from virtualdub) to AVI using "AVI-Mux GUI," something I think can too be done straight using virtualdub, choosing "audio from file" for audio (is that right, that avi-mux gui thus would not be needed?).

However, I'm blocked in a particular step... Whatever I do using mp3packer, MediaInfo always say that the output file's bitrate remains "variable" and not, as I would want it, "constant."

I've spent all week on this thing. I feel I'm approaching the point where I can fix my AVI file (I want it to remain AVI so as to be DVD-player watchable) without re-encoding, thus without losing quality.

Thanks,
twipley

Re-encoding, with goal of "preserving quality"

Reply #11
IIRC max. bitrate for MPEG-2 (22.05 kHz) layer3 is 160 kbps.

Does this mean I should go with -b 160 using mp3packer?

Re-encoding, with goal of "preserving quality"

Reply #12
Mp3packer will print min. possible CBR bitrate with --ib option:

Code: [Select]
mp3packer --ib file.mp3

Re-encoding, with goal of "preserving quality"

Reply #13
Quote
2) output wav using virtualdub, output mp3 file using lamedrop, then use mp3repacker


This is very... er, strange way. And it also results in quality loss.

Extract mp3 file from AVI (e.g. with VirtualDubMod), apply mp3packer and add resulting mp3 to AVI.

Re-encoding, with goal of "preserving quality"

Reply #14
Alright. Worked great extracting mp3 file using "virtualdubmod > streams > stream list > demux."

--ib indeed prints 160. So, I intuit I should go with "mp3packer -b 160 file.mp3" or the like, if I understand correctly?

As a side note, "mp3packer -b 162 file.mp3" produced about the same file, however with 4:58 duration (see info below) instead of the original, 4:57 duration (which 160 succeeded in reproducing).

Code: [Select]
Audio
Format                           : MPEG Audio
Format version                   : Version 2
Format profile                   : Layer 3
Mode                             : Joint stereo
Mode extension                   : MS Stereo
Duration                         : 4mn 58s
Bit rate mode                    : Constant
Bit rate                         : 160 Kbps
Channel(s)                       : 2 channels
Sampling rate                    : 22.05 KHz
Stream size                      : 5.69 MiB (100%)

The reason I've tried with 162 is that, while -i prints out 160 as "smallest bitrate for CBR," it does print out "largest frame uses [...] 161.36 kbps." Strange, isn't it? 

Furthermore, consulting the mp3packer readme makes me realize I do not understand much of these internals:
Code: [Select]
Minimum bitrate allowed for output. Defaults to 0, which means all frame sizes are allowed. If the number given is a valid bitrate, the minimum frame size will be "dithered" between padded and unpadded frames, depending on standard CBR rules. If the bitrate given is one more than a valid bitrate, all frames will be padded. Anything larger than the maximum bitrate will be clamped to a padded maximum-bitrate frame. All other bitrates will round up to the next higher unpadded frame.

Could you confirm that the used command line indeed (theoretically speaking) has not left any significant bits behind?

Re-encoding, with goal of "preserving quality"

Reply #15
I would use a modern container like MP4 or MKV.

Re-encoding, with goal of "preserving quality"

Reply #16
But, AVI is compatible with my DVD player.

EDIT: up there, when I say "strange," I'm talking about the modified duration (i.e. 4:58).

The only thing really tying me to this thread is waiting for the following confirmation:
"the number one should use for -b # is the one that is given in the --ib print."

-- I am preparing a short readme for the solution for the doom9 thread, and, being on sloppy ground, I would not want to post inaccurate information.

Re-encoding, with goal of "preserving quality"

Reply #17
You don't need VirtualDubMod to extract the MP3 from the AVI file. Just use the Extract -> Raw audio in VirtualDub. It'll output xxx.bin, and then all you need to do is change the extension to .mp3.

Re-encoding, with goal of "preserving quality"

Reply #18
You don't need VirtualDubMod to extract the MP3 from the AVI file. Just use the Extract -> Raw audio in VirtualDub. It'll output xxx.bin, and then all you need to do is change the extension to .mp3.

Awesome. This contributes to shortening the length of my readme solution, which is a good thing (think parsimoniousness):

Code: [Select]
I've just spent a some time over at the nice and expansive Hydrogenaudio Forums. There, two options were being offered to me:

1) resampling (to unlock vd's CBR encoding) and CBR reencode using virtualdub, but that might, as some suggested, result in audio-quality loss;

2) outputing audio through "file > export > raw audio," video through "audio > no audio; video > direct stream copy; file > save as avi," both using virtualdub, then, secondly, using mp3packer to, "losslessly convert [i.e. without re-encoding] from VBR to CBR, basically just by padding every frame with 0s" (using the same "-b #" as "--ib" prints out), and, finally, remuxing audio (coming from mp3repacker) together with video (coming from virtualdub) to a final AVI file using AVI-Mux GUI.

Thus, needed software:
- virtualdub
- mp3packer
- avimuxgui

Re-encoding, with goal of "preserving quality"

Reply #19
You don't need avimuxgui actually:
1) Extract raw audio in VDub
2) use mp3packer
3) return to VDub and select: Video > Direct stream copy; Audio > Audio from other file... (select proper mp3 file) and then File > Save as AVI...

Re-encoding, with goal of "preserving quality"

Reply #20
Nice suggestion. I was just experimenting with that at the moment, actually. I've found that avimuxgui produces "Aligned on interleaves" by default, whereas by default virtualdub produces "Split across interleaves." Not really wanting to fiddle more than I to this point have, I've kept avimuxgui as the third tool, some people having suggested "aligned" being a secure means of further avoiding sync problems.

source:
http://forum.videohelp.com/threads/232996-...dio-interleaves
http://www.fixya.com/support/r4099743-set_...gn_audio_frames

However, your method seems very fast. Outputted files seem, for some reason, to be 200k bigger that way, though.

I hope someday this thread will benefit someone to read.

Peace out,
twipley

Re-encoding, with goal of "preserving quality"

Reply #21
VirtualDub lets you configure how you want to mux the audio in one of the audio menus. IIRC it's the "Interleaving" one.