I can answer question A a bit. you can when saving your file choose your own setting when going to produce > choose your file format for example h.264, then press the + button and then you can choose the bit rate you want

Quote: I can answer question A a bit. you can when saving your file choose your own setting when going to produce > choose your file format for example h.264, then press the + button and then you can choose the bit rate you want

Thanks Merljjin, I'm definitely doing that and in my profile I have selected 192kbps.
But still the output of the rendered file is always something small like 87kpbs or 111kpbs or something..

As an experiment, I set the profile to have 256kbps and 384kbps audio, on both encodes they both have 111kpbs in the final outputted file.

Normally it shouldn't change the audio quality if you don't change anything. It's confusing me to

Quote: Normally it shouldn't change the audio quality if you don't change anything. It's confusing me to

Yeh that's what I thought too.

So for example

* Input source file 128kbps/stereo Audio

* Power Director render settings - 192kpbs/ stereo Audio

* Output file - depending on which source file I use ranges between 87-111Kbps.

Like its cropping the audio some how ?


EDIT: Did a Test on another video which has an AC3 track on it which much higher audio bit rate.
Encoded ith 192kbps Audio setting and the file comes out with 176Kbps!!??

If I use H264 or WMV or any other file types I get exactly the same number as the encode parameters.
Only MPEG4 seems to output sill number

Quote:

Quote: Normally it shouldn't change the audio quality if you don't change anything. It's confusing me to

Yeh that's what I thought too.

So for example

* Input source file 128kbps/stereo Audio

* Power Director render settings - 192kpbs/ stereo Audio

* Output file - depending on which source file I use ranges between 87-111Kbps.

Like its cropping the audio some how ?


EDIT: Did a Test on another video which has an AC3 track on it which much higher audio bit rate.
Encoded ith 192kbps Audio setting and the file comes out with 176Kbps!!??

If I use H264 or WMV or any other file types I get exactly the same number as the encode parameters.
Only MPEG4 seems to output sill number

I think what you notice is normal. For H.264, the AC3 audio codec is typically used. This codec only offers constant bitrate (CBR) to consumers so what you set in PD is what you will see in the output.

For MPEG4, the AAC audio codec is used. This codec does support many variants of audio bitrate control (CBR, VBR, CVBR, ABR), since PD gives the user no real control, I believe they have adapted some form of variable bitrate control for you. Hence your observations, depending what audio file you encode, the variable bitrate encoder settings (PD internal) provides differing bitrates of your encoded files because that's what a variable bitrate does. Variable based on audio complexity. Often, ABR (average bit rate) is the default for AAC encoding, however, I'm not exactly sure what PD has incorporated.

MediaInfo of the file will shed some light, but in my opinion can be confusing here as I've seen in report "constant" for audio bitrate when in fact it appears variable and also reports a avg audio bitrate.

Jeff

I don't believe this is correct behavior for this program, and it is not the way it does my files. For instance, I'm currently in the process of editing some MP4 files that I've downloaded from the Internet, and the audio specs (via MediaInfo) are 192 Kbps, 44.1 KHz, 2 Channels, AAC (LC). After splitting, editing and Producing them to the original format, MP4 (NOT H.264) the audio specs are exactly the same, having been set that way in the profile.

One thing that may or may not be a factor, before editing my audio I always convert it to .WAV format before taking it into Audio Director to edit. It may not make any difference, but when I first started using this program some video that I had extensively edited, such as boosting the sound levels by 10 or more decibels, sounded scratchy, and I read somewhere in these pages that that might help. For whatever reason, I haven't had any scratchy sound tracks since then. You may want to try this to see if it will work for your problem. Dell Precision 7510 Laptop
Windows 7 Pro 64-bit | Intel(R) XEON(R) CPU E3-1505M v5 @2.80 GHz
RAM: 32 GB
Windows Experience Index 7.5

BillyR,

Post a small output sample clip of your edited MP4 and MediaInfo file if you can.

A WAV file is always CBR (constant bit rate) but that shouldn't matter here as it would need to be re-encoded for MP4 anyhow.

Jeff

Interesting...

Whe I edit the audio first in Audio Director then put back into the timeline, the produce, the audio bit rate is exactly what the parameter says it will be.

Maybe I have to do that each time (convert to wav and reimport)
But its a real pain to have to do one clip at a time or export everything and reimport again

"One way around this, to achieve your purpose, would be to produce your PD project to an audio only format (WAV, WMA etc) and import that file into AudioDirector for editing. "

Here is the media info of a clip produced with 192kbps but shows a bitrate of constant rate of 100kpbs in the output file, which is a fair bit off the 128kbps of the source.
I would expect to see an up-sample to 192kbps rather than a down-sample to 100kpbs


General
Complete name : C:\Users\dli21\Videos\Video Editing\Produce_7.mp4
Format : MPEG-4
Format profile : Sony PSP
Codec ID : MSNV
File size : 7.40 MiB
Duration : 10s 130ms
Overall bit rate : 6 131 Kbps
Encoded date : UTC 2014-07-17 22:04:56
Tagged date : UTC 2014-07-17 22:04:56

Video
ID : 1
Format : AVC
Format/Info : Advanced Video Codec
Format profile : High@L3.1
Format settings, CABAC : Yes
Format settings, ReFrames : 2 frames
Format settings, GOP : M=2, N=29
Codec ID : avc1
Codec ID/Info : Advanced Video Coding
Duration : 10s 100ms
Bit rate : 6 043 Kbps
Width : 1 280 pixels
Height : 720 pixels
Display aspect ratio : 16:9
Frame rate mode : Constant
Frame rate : 30.000 fps
Color space : YUV
Chroma subsampling : 4:2:0
Bit depth : 8 bits
Scan type : Progressive
Bits/(Pixel*Frame) : 0.219
Stream size : 7.28 MiB (98%)
Language : English
Encoded date : UTC 2014-07-17 22:04:56
Tagged date : UTC 2014-07-17 22:04:56

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 10s 130ms
Duration_FirstFrame : -4ms
Bit rate mode : Constant
Bit rate : 100 Kbps
Nominal bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 124 KiB (2%)
Language : English
Encoded date : UTC 2014-07-17 22:04:56
Tagged date : UTC 2014-07-17 22:04:56
mdhd_Duration : 10130



File attached

Quote: BillyR,

Post a small output sample clip of your edited MP4 and MediaInfo file if you can.

A WAV file is always CBR (constant bit rate) but that shouldn't matter here as it would need to be re-encoded for MP4 anyhow.

Jeff

Well now this is a puzzlement. I couldn't use my current editing machine as it's busy rendering, but I cut out a 10 second portion of one of my edited MP4s on my old i7 950 using the same parameters and lo & behold the MediaInfo showed a bitrate of 106 Kbps and a nominal bitrate of 192. So I tried the trick of converting the audio to a WAV file first and it still came out that way. Then I went back and looked at the first dozen clips I've done during this current session and they all show a bitrate of 192. Then I looked at the two I've done today using the same profile as I used with the others and one shows a bitrate of 106 and the other 177, both showing a nominal bitrate of 192. So for some reason after a dozen clips rendered with a solid bitrate of 192 suddenly, using the exact same profile on the same machine, PD has decided to render mine like it's doing li21s. All the other parameters look the same, but when I have the time I'll have to study them closer. I was using files from the same source that I downloaded today, and they also look the same as the ones I downloaded previously, but I'll have to compare those more closely when time permits. Right now I have to finish my editing projects. Dell Precision 7510 Laptop
Windows 7 Pro 64-bit | Intel(R) XEON(R) CPU E3-1505M v5 @2.80 GHz
RAM: 32 GB
Windows Experience Index 7.5

li21, your MediaInfo is as typical of what I have seen with PD. Notice the lines of:
Bit rate : 100 Kbps
Nominal bit rate : 192 Kbps

Below is the pertinent MediaInfo for your file produced with a true CBR 192Kbps AAC encoder. Notice no reference to a "Nominal bit rate" like the PD output results you posted and the Bit rate is indeed 192Kbps as I had specified.

Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 10s 155ms
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 237 KiB (2%)
Language : English
Encoded date : UTC 2014-07-16 22:36:26
Tagged date : UTC 2014-07-16 22:36:26

I'm still under the opinion that maybe PD with no third party codec packages installed simply uses a variable bit rate encoding for the AAC profiles under MPEG-4 which would be pretty standard. I'm curious to see BillyR's post of his sample PD MPEG-4 with WYSIWYG results, I've not seen that in PD MPEG-4 created files and apparently not you either. Very system dependent I guess.

Jeff

Thank you BillyR!

Good to know that I know I'm not the only one!
But wonder if this is a bug that will need to be reported

Well now this is getting curiouser and curiouser! Here's the pertinent info from one of the files that I rendered today that showed the bitrate anamoly:
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 33mn 0s
Source duration : 33mn 0s
Bit rate mode : Constant
Bit rate : 177 Kbps
Nominal bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 41.9 MiB (6%)
Source stream size : 41.9 MiB (6%)
Language : English
Encoded date : UTC 2014-07-17 22:20:04
Tagged date : UTC 2014-07-17 22:20:04
mdhd_Duration : 1980669

Here's the info from the next one I rendered about 2 and a half hours later, completed about 30 min. ago, which is extracted from the same master file as the one above and done with the same profile. As you can see, it's a solid 192 Kbps:
Audio
ID : 2
Format : AAC
Format/Info : Advanced Audio Codec
Format profile : LC
Codec ID : 40
Duration : 45mn 6s
Source duration : 45mn 6s
Bit rate mode : Constant
Bit rate : 192 Kbps
Channel(s) : 2 channels
Channel positions : Front: L R
Sampling rate : 48.0 KHz
Compression mode : Lossy
Stream size : 59.0 MiB (6%)
Source stream size : 59.0 MiB (6%)
Language : English
Encoded date : UTC 2014-07-18 00:57:43
Tagged date : UTC 2014-07-18 00:57:43
mdhd_Duration : 2706343

So on my machine at least, the behavior is not consistent.

I didn't use H.264 for these files since the originals weren't in that format, but this may be a good argument for using it. These are HD classical music videos, and good sound is a must. I've never noticed the artifacts that i21 mentions, but I'm going to redo one of the clips that showed the bitrate problem tomorrow morning with H.264 and the Dolby Digital codec and compare them. May try the LPCM one too if those results aren't satisfactory. Meanwhile, time for some zzzzzzz's.

Dell Precision 7510 Laptop
Windows 7 Pro 64-bit | Intel(R) XEON(R) CPU E3-1505M v5 @2.80 GHz
RAM: 32 GB
Windows Experience Index 7.5

Interesting too, I just spent a bunch of time stripping audio into a WAV (512kbps is the lowest option) and rejoining to my timeline.. producing and guess what.. the audio is now showing as 82Kpbs!

Very inconsistent.

I would use H264 instead of MP4 but the artifacts I get make me steer clear. So for me its a question of Audio (h264 wins) vs Visual (Meg4 wins)

JL_JL I dont seem to have this issue when I encode with HAndbrake and Mp4 H264.
All the audio is consistent and appears to be CBR?

Is it even possible to import some other audio codec into PD for rendering ?

Quote: JL_JL I dont seem to have this issue when I encode with HAndbrake and Mp4 H264.
All the audio is consistent and appears to be CBR?

Is it even possible to import some other audio codec into PD for rendering ?

'Morning, all. After sleeping on this I decided to try redoing one of my files that had the issue, since I have now done two since then that encoded at 192. I tried it, and unfortunately the file still shows 106 (192). Your question prompted me to make a search, and I found this 3 year old post by Dafyyd: http://tinyurl.com/nqgptf4

Then I searched for ffdshow and found it here: http://tinyurl.com/2ongjk. I couldn't find any instructions for configuring PD12 with it, so started re-rendering the file mentioned above for a third time. It'll be done in about an hour and 45 min., and I'll report my results here.

Meanwhile, if anyone knows of a procedure to incorporate different codes into PD it would be nice if you were to share that info here.

I think if this fails I'll resort to rendering the same file with H.264 and see what happens. Dell Precision 7510 Laptop
Windows 7 Pro 64-bit | Intel(R) XEON(R) CPU E3-1505M v5 @2.80 GHz
RAM: 32 GB
Windows Experience Index 7.5

Finished the rendering mentioned in the post above with the same result. Since no one has provided any info on a procedure to configure PD with different codecs, I've uninstalled ffdshow and begun rendering the same file as H.264 with the Dolby Digital codec.

I checked out a H.264 clip that I rendered some time ago and couldn't detect any artifacts, even when I magnified a screen capture in Paint by 2 or 3X. However, that clip was rendered at 22.7 Mbps, while the clips I'm dealing with here are being rendered at 3000 Kbps. When it's complete I'll compare the results of this clip with the same one rendered at MP4. Dell Precision 7510 Laptop
Windows 7 Pro 64-bit | Intel(R) XEON(R) CPU E3-1505M v5 @2.80 GHz
RAM: 32 GB
Windows Experience Index 7.5

I haven't uninstalled ffdshow yet

But I swear I'm my h264 profile I created I asked for 192kbs and the rendered file gave me 256kbps.

Anyways not sure if it's because my 1080p clips are using too low a bit rate but there's definitely a difference on h264 and MPEG4 still. I particularly noticed a loss of detail in say scenes where a person is wearing a polka dot dress in the distance .. The dots become blurry so there's no dots visible in the h264 and still visible in the mpeg4
That is with both clips rendered with a quite a low bitrate of 8500kbps at 1080p 30fps. (Trying to produce the best acceptable quaily with lowest file size)

I thought I couldn't tell whether the audio was at 128kbps or at 105kpbs or whatever it comes out to, but I think I can detect some sqealch. I wouldn't be happy in the back of my mind if there was any quality loss in audio since the source (GoPRo) isn't that great to begin with.

Well, I've now rendered 2 files since the last one that didn't encode at the full 192 Kbps, and they've both rendered properly (at the full 192). I'm in the process of rendering the final one of 16. If that one renders properly my score will be 14 - 2, the 14 being the proper bitrate and the two with the degraded bitrate. My files are 720p 25 fps 1700 Kbps downloaded from Israel, which is apparently a PAL country. It's a weird combination, but I'm trying to stay as close to the original parameters as possible. The only reason I'm encoding at 3000 Kbps is that's as low as PD will go for this size file. In spite of that, they look very good to my eye.

I've compared the same MP4 and M2TS on a 60" HDTV and still can't see any difference. Also can't see any difference on screen shots magnified 3X. However, like you, I CAN tell the difference between a 106 Kbps AAC sound track and a 192 Kbps AC-3 one, so I replaced that one with the M2TS. However, the 177 Kbps one was fine, so I kept it. So in the end, I only had to replace one clip, provided the one that's working now renders properly.

One more option, in future if a clip fails to render at 192, I'm going to try 256 and see what that does. Involves another couple of hours of rendering, but if it doesn't happen any more often than it has in this job that's not too bad. Hopefully it will be corrected, but if it happens too often I'll start using H.264 unless/until PD fixes it.

In any case, it looks to me like you've discovered a fault in this program, confirmed by me (although mine is intermittent while yours seems to be constant), and you may want to report it to Tech Support. Dell Precision 7510 Laptop
Windows 7 Pro 64-bit | Intel(R) XEON(R) CPU E3-1505M v5 @2.80 GHz
RAM: 32 GB
Windows Experience Index 7.5

I'd probably submit it to support and see what they say. I'd like to read the response. I still believe they must be using some form bitrate control based on complexity of audio. That thought may also fit the wondering experience documented by BillyR for his clips.

I created various audio forms of increasing complexity. My time line was nothing more than 30second black color board and then my imported WAV audio in track 1. For the last documented case, the white noise stereo was added to track 2 while keeping the simplistic mono sound in track 1.

I created 3 custom MPEG-4 profiles based on the default 1920x1080 13Mbps profile with audio bitrates of 96, 192, and 256.

The results are in the attached table. One can easily see the final result from PD encoding is a very strong function of audio complexity which really hints towards some form of bitrate control.

Jeff