Discussion:
Export Options WAS: (Export Multiple) Options dialog goes on top of all applications in windows XP
(too old to reply)
Gale Andrews
2008-06-20 17:56:57 UTC
Permalink
|
LRN
2008-06-21 09:51:15 UTC
Permalink
|
Richard Ash
2008-06-22 15:37:17 UTC
Permalink
I'll look into it.
How does "external program" works exactly? Audacity feeds WAV to
process' stdin?
Yes, a WAV file with 16 bit data in it. Mono/Stereo depending on the
project contents, project sample rate (try 'file -' as the command and
show program output to see what a given project produces).

For me, external program exports are working OK - I've just done a 40
minute export to Ogg Vorbis using oggenc OK.
You said the individual format listings for "uncompressed"
types in the export dialogue was temporary, what's the
* WAV or AIFF (uncompressed)
* Other uncompressed types
It's not for me to decide. The list of uncompressed types was just a way
to demonstrate new exporting procedure (FFmpeg exporter didn't existed
at the moment, and it's still not in tree even now).
I think i'll just shrink the list back to one option - there's almost
zero differences between "uncompressed types". Unless someone explicitly
asks me to keep some of the exported types as separate entries and
explains why it is necessary.
I would suggest "Default WAV" pointing to 16-bit PCM WAV and "Default
AIFF" pointing to 16-bit AIFF as convenience entries for people creating
CDs, the rest all go into the uncompressed types entry (if people want
other sorts of WAV / AIFF they would do them by clicking options from
"other", I wouldn't want Default WAV to be changeable to some other bit
depth, because in a lot of software there is only one sort of WAV - 16
bit.

Richard
Richard Ash
2008-06-22 16:12:38 UTC
Permalink
I think i'll just shrink the list back to one option - there's almost
zero differences between "uncompressed types". Unless someone explicitly
asks me to keep some of the exported types as separate entries and
explains why it is necessary.
At the moment there is also a bug - if you export one file, choosing WAV
and selecting 32-bit encoding, it exports 32-bit data. If you then go
back to do another export, then the encoding has been changed back to
16-bit, so you have to remember to keep changing it to the correct
value. You didn't use to have to do this - it used to remember your
format choices between exports.

Richard
LRN
2008-06-22 17:43:04 UTC
Permalink
Post by Richard Ash
I think i'll just shrink the list back to one option - there's almost
zero differences between "uncompressed types". Unless someone explicitly
asks me to keep some of the exported types as separate entries and
explains why it is necessary.
At the moment there is also a bug - if you export one file, choosing WAV
and selecting 32-bit encoding, it exports 32-bit data. If you then go
back to do another export, then the encoding has been changed back to
16-bit, so you have to remember to keep changing it to the correct
value. You didn't use to have to do this - it used to remember your
format choices between exports.
Fixed.
Gale Andrews
2008-07-12 07:03:37 UTC
Permalink
Hi LRN

I built following Martyn's suggestion of removing NoteTrack.cpp and
ImportMIDI.cpp, then tried exporting some stereo MP4 (AAC) files
against your fix for profile not being correctly exported. Checking the
exported files in iTunes, I got:

8 kbps LC > iTunes: 18 kbps LC
16 kbps Main > iTunes: 19 kbps no profile
32 kbps SSR > null file 0 bytes
32 kbps LTP > iTunes: 22 kbps no profile

Should 32 kbps per channel in Audacity end up as 64 kbps given I had
a stereo file?

DBPowerAmp sees the correct profile for the three files that exported,
but has 0 kbps bit rate. Foobar 2000 displays all the exported profiles
correctly, and displays the same bit rates as iTunes (i.e. not what
Audacity exported).

SSR profile also produces null files when exporting AAC.

Exporting "WAV (Microsoft) 16 bit PCM" now gives 16 bit even if you
choose some other sample format. I think that's correct, but also think you
should grey out the OK button when choosing any of the other options,
or remove them from the list.


Thanks


Gale
LRN
2008-07-12 14:02:26 UTC
Permalink
8 kbps LC> iTunes: 18 kbps LC
16 kbps Main> iTunes: 19 kbps no profile
32 kbps SSR> null file 0 bytes
32 kbps LTP> iTunes: 22 kbps no profile
Should 32 kbps per channel in Audacity end up as 64 kbps given I had
a stereo file?
DBPowerAmp sees the correct profile for the three files that exported,
but has 0 kbps bit rate. Foobar 2000 displays all the exported profiles
correctly, and displays the same bit rates as iTunes (i.e. not what
Audacity exported).
Actually, it said "per channel", but in reality it was "per whole file",
because FFmpeg is making the bitrate/channels division internally.
Part of the problem is that max supported bitrate is per channel only,
and it depends on samplerate.
I know how to handle that, but ShuttleGui is resisting my attempts to
change the data.
SSR profile also produces null files when exporting AAC.
After some digging in libfaac source code i found out that SSR is not
supported. D'oh.
Exporting "WAV (Microsoft) 16 bit PCM" now gives 16 bit even if you
choose some other sample format. I think that's correct, but also think you
should grey out the OK button when choosing any of the other options,
or remove them from the list.
Fixed.
Gale Andrews
2008-07-13 03:45:58 UTC
Permalink
|
LRN
2008-07-13 03:55:25 UTC
Permalink
|
LRN
2008-07-13 06:17:01 UTC
Permalink
|
Gale Andrews
2008-07-13 16:51:15 UTC
Permalink
|
LRN
2008-07-13 19:08:10 UTC
Permalink
|
Gale Andrews
2008-07-14 02:20:59 UTC
Permalink
|
LRN
2008-07-14 09:41:37 UTC
Permalink
|
Gale Andrews
2008-07-15 19:15:15 UTC
Permalink
|
LRN
2008-07-16 05:11:16 UTC
Permalink
|
Gale Andrews
2008-07-16 18:40:50 UTC
Permalink
|
LRN
2008-07-19 15:30:32 UTC
Permalink
I installed iTunes again and made a couple of tests. I am positive that
iTunes v7.7.0.43 is unable to play MP4/MOV/etc AAC files, encoded by
ffmpeg (using ffmpeg.exe -i file.wav -acodec libfaac -ar xxx -ab yyy
-cutoff zzz -f fmt file.mp4 or similar commandline; ffmpeg of version
git-c83671b at 11 June 2008), unless it's LC-AAC.

As for bitrate, i encoded 2400 audio files in a few days, and here's the
results for 480 of them (others are the same, just in different format,
i.e. ipod, 3gp, mov, etc - it seems that iTunes accepts any mov-based
format as long as it is LC-AAC, and foobar2000 accepts almost anything,
except maybe mov):
001 rock.short.wav_-ab_92000_-ar_22050_aac_low_-cutoff_0_-f_mp4
76 kbps
002 rock.short.wav_-ab_92000_-ar_22050_aac_low_-cutoff_220_-f_mp4
8 kbps
003 rock.short.wav_-ab_92000_-ar_22050_aac_low_-cutoff_551_-f_mp4
14 kbps
004 rock.short.wav_-ab_92000_-ar_22050_aac_low_-cutoff_1102_-f_mp4
24 kbps
005 rock.short.wav_-ab_92000_-ar_22050_aac_low_-cutoff_2450_-f_mp4
47 kbps
006 rock.short.wav_-ab_92000_-ar_22050_aac_low_-cutoff_3150_-f_mp4
58 kbps
007 rock.short.wav_-ab_92000_-ar_22050_aac_low_-cutoff_4410_-f_mp4
75 kbps
008 rock.short.wav_-ab_92000_-ar_22050_aac_low_-cutoff_11025_-f_mp4
92 kbps
009 rock.short.wav_-ab_92000_-ar_22050_aac_ltp_-cutoff_0_-f_mp4
76 kbps
010 rock.short.wav_-ab_92000_-ar_22050_aac_ltp_-cutoff_220_-f_mp4
8 kbps
011 rock.short.wav_-ab_92000_-ar_22050_aac_ltp_-cutoff_551_-f_mp4
14 kbps
012 rock.short.wav_-ab_92000_-ar_22050_aac_ltp_-cutoff_1102_-f_mp4
25 kbps
013 rock.short.wav_-ab_92000_-ar_22050_aac_ltp_-cutoff_2450_-f_mp4
47 kbps
014 rock.short.wav_-ab_92000_-ar_22050_aac_ltp_-cutoff_3150_-f_mp4
58 kbps
015 rock.short.wav_-ab_92000_-ar_22050_aac_ltp_-cutoff_4410_-f_mp4
76 kbps
016 rock.short.wav_-ab_92000_-ar_22050_aac_ltp_-cutoff_11025_-f_mp4
92 kbps
017 rock.short.wav_-ab_92000_-ar_22050_aac_main_-cutoff_0_-f_mp4
76 kbps
018 rock.short.wav_-ab_92000_-ar_22050_aac_main_-cutoff_220_-f_mp4
8 kbps
019 rock.short.wav_-ab_92000_-ar_22050_aac_main_-cutoff_551_-f_mp4
14 kbps
020 rock.short.wav_-ab_92000_-ar_22050_aac_main_-cutoff_1102_-f_mp4
24 kbps
021 rock.short.wav_-ab_92000_-ar_22050_aac_main_-cutoff_2450_-f_mp4
47 kbps
022 rock.short.wav_-ab_92000_-ar_22050_aac_main_-cutoff_3150_-f_mp4
58 kbps
023 rock.short.wav_-ab_92000_-ar_22050_aac_main_-cutoff_4410_-f_mp4
75 kbps
024
rock.short.wav_-ab_92000_-ar_22050_aac_main_-cutoff_11025_-f_mp4
92 kbps
025 rock.short.wav_-ab_92000_-ar_44100_aac_low_-cutoff_0_-f_mp4
92 kbps
026 rock.short.wav_-ab_92000_-ar_44100_aac_low_-cutoff_441_-f_mp4
15 kbps
027 rock.short.wav_-ab_92000_-ar_44100_aac_low_-cutoff_1102_-f_mp4
29 kbps
028 rock.short.wav_-ab_92000_-ar_44100_aac_low_-cutoff_2205_-f_mp4
48 kbps
029 rock.short.wav_-ab_92000_-ar_44100_aac_low_-cutoff_4900_-f_mp4
91 kbps
030 rock.short.wav_-ab_92000_-ar_44100_aac_low_-cutoff_6300_-f_mp4
92 kbps
031 rock.short.wav_-ab_92000_-ar_44100_aac_low_-cutoff_8820_-f_mp4
92 kbps
032 rock.short.wav_-ab_92000_-ar_44100_aac_low_-cutoff_22050_-f_mp4
126 kbps
033 rock.short.wav_-ab_92000_-ar_44100_aac_ltp_-cutoff_0_-f_mp4
92 kbps
034 rock.short.wav_-ab_92000_-ar_44100_aac_ltp_-cutoff_441_-f_mp4
15 kbps
035 rock.short.wav_-ab_92000_-ar_44100_aac_ltp_-cutoff_1102_-f_mp4
29 kbps
036 rock.short.wav_-ab_92000_-ar_44100_aac_ltp_-cutoff_2205_-f_mp4
48 kbps
037 rock.short.wav_-ab_92000_-ar_44100_aac_ltp_-cutoff_4900_-f_mp4
91 kbps
038 rock.short.wav_-ab_92000_-ar_44100_aac_ltp_-cutoff_6300_-f_mp4
92 kbps
039 rock.short.wav_-ab_92000_-ar_44100_aac_ltp_-cutoff_8820_-f_mp4
92 kbps
040 rock.short.wav_-ab_92000_-ar_44100_aac_ltp_-cutoff_22050_-f_mp4
126 kbps
041 rock.short.wav_-ab_92000_-ar_44100_aac_main_-cutoff_0_-f_mp4
92 kbps
042 rock.short.wav_-ab_92000_-ar_44100_aac_main_-cutoff_441_-f_mp4
15 kbps
043 rock.short.wav_-ab_92000_-ar_44100_aac_main_-cutoff_1102_-f_mp4
29 kbps
044 rock.short.wav_-ab_92000_-ar_44100_aac_main_-cutoff_2205_-f_mp4
48 kbps
045 rock.short.wav_-ab_92000_-ar_44100_aac_main_-cutoff_4900_-f_mp4
91 kbps
046 rock.short.wav_-ab_92000_-ar_44100_aac_main_-cutoff_6300_-f_mp4
92 kbps
047 rock.short.wav_-ab_92000_-ar_44100_aac_main_-cutoff_8820_-f_mp4
92 kbps
048
rock.short.wav_-ab_92000_-ar_44100_aac_main_-cutoff_22050_-f_mp4
126 kbps
049 rock.short.wav_-ab_92000_-ar_48000_aac_low_-cutoff_0_-f_mp4
92 kbps
050 rock.short.wav_-ab_92000_-ar_48000_aac_low_-cutoff_480_-f_mp4
17 kbps
051 rock.short.wav_-ab_92000_-ar_48000_aac_low_-cutoff_1200_-f_mp4
31 kbps
052 rock.short.wav_-ab_92000_-ar_48000_aac_low_-cutoff_2400_-f_mp4
52 kbps
053 rock.short.wav_-ab_92000_-ar_48000_aac_low_-cutoff_5333_-f_mp4
92 kbps
054 rock.short.wav_-ab_92000_-ar_48000_aac_low_-cutoff_6857_-f_mp4
92 kbps
055 rock.short.wav_-ab_92000_-ar_48000_aac_low_-cutoff_9600_-f_mp4
92 kbps
056 rock.short.wav_-ab_92000_-ar_48000_aac_low_-cutoff_24000_-f_mp4
133 kbps
057 rock.short.wav_-ab_92000_-ar_48000_aac_ltp_-cutoff_0_-f_mp4
92 kbps
058 rock.short.wav_-ab_92000_-ar_48000_aac_ltp_-cutoff_480_-f_mp4
17 kbps
059 rock.short.wav_-ab_92000_-ar_48000_aac_ltp_-cutoff_1200_-f_mp4
31 kbps
060 rock.short.wav_-ab_92000_-ar_48000_aac_ltp_-cutoff_2400_-f_mp4
52 kbps
061 rock.short.wav_-ab_92000_-ar_48000_aac_ltp_-cutoff_5333_-f_mp4
92 kbps
062 rock.short.wav_-ab_92000_-ar_48000_aac_ltp_-cutoff_6857_-f_mp4
92 kbps
063 rock.short.wav_-ab_92000_-ar_48000_aac_ltp_-cutoff_9600_-f_mp4
92 kbps
064 rock.short.wav_-ab_92000_-ar_48000_aac_ltp_-cutoff_24000_-f_mp4
134 kbps
065 rock.short.wav_-ab_92000_-ar_48000_aac_main_-cutoff_0_-f_mp4
92 kbps
066 rock.short.wav_-ab_92000_-ar_48000_aac_main_-cutoff_480_-f_mp4
17 kbps
067 rock.short.wav_-ab_92000_-ar_48000_aac_main_-cutoff_1200_-f_mp4
31 kbps
068 rock.short.wav_-ab_92000_-ar_48000_aac_main_-cutoff_2400_-f_mp4
52 kbps
069 rock.short.wav_-ab_92000_-ar_48000_aac_main_-cutoff_5333_-f_mp4
92 kbps
070 rock.short.wav_-ab_92000_-ar_48000_aac_main_-cutoff_6857_-f_mp4
92 kbps
071 rock.short.wav_-ab_92000_-ar_48000_aac_main_-cutoff_9600_-f_mp4
92 kbps
072
rock.short.wav_-ab_92000_-ar_48000_aac_main_-cutoff_24000_-f_mp4
133 kbps
073 rock.short.wav_-ab_92000_-ar_88200_aac_low_-cutoff_0_-f_mp4
118 kbps
074 rock.short.wav_-ab_92000_-ar_88200_aac_low_-cutoff_882_-f_mp4
30 kbps
075 rock.short.wav_-ab_92000_-ar_88200_aac_low_-cutoff_2205_-f_mp4
57 kbps
076 rock.short.wav_-ab_92000_-ar_88200_aac_low_-cutoff_4410_-f_mp4
92 kbps
077 rock.short.wav_-ab_92000_-ar_88200_aac_low_-cutoff_9800_-f_mp4
93 kbps
078 rock.short.wav_-ab_92000_-ar_88200_aac_low_-cutoff_12600_-f_mp4
107 kbps
079 rock.short.wav_-ab_92000_-ar_88200_aac_low_-cutoff_17640_-f_mp4
134 kbps
080 rock.short.wav_-ab_92000_-ar_88200_aac_low_-cutoff_44100_-f_mp4
203 kbps
081 rock.short.wav_-ab_92000_-ar_88200_aac_ltp_-cutoff_0_-f_mp4
118 kbps
082 rock.short.wav_-ab_92000_-ar_88200_aac_ltp_-cutoff_882_-f_mp4
30 kbps
083 rock.short.wav_-ab_92000_-ar_88200_aac_ltp_-cutoff_2205_-f_mp4
57 kbps
084 rock.short.wav_-ab_92000_-ar_88200_aac_ltp_-cutoff_4410_-f_mp4
92 kbps
085 rock.short.wav_-ab_92000_-ar_88200_aac_ltp_-cutoff_9800_-f_mp4
93 kbps
086 rock.short.wav_-ab_92000_-ar_88200_aac_ltp_-cutoff_12600_-f_mp4
107 kbps
087 rock.short.wav_-ab_92000_-ar_88200_aac_ltp_-cutoff_17640_-f_mp4
134 kbps
088 rock.short.wav_-ab_92000_-ar_88200_aac_ltp_-cutoff_44100_-f_mp4
204 kbps
089 rock.short.wav_-ab_92000_-ar_88200_aac_main_-cutoff_0_-f_mp4
118 kbps
090 rock.short.wav_-ab_92000_-ar_88200_aac_main_-cutoff_882_-f_mp4
30 kbps
091 rock.short.wav_-ab_92000_-ar_88200_aac_main_-cutoff_2205_-f_mp4
57 kbps
092 rock.short.wav_-ab_92000_-ar_88200_aac_main_-cutoff_4410_-f_mp4
92 kbps
093 rock.short.wav_-ab_92000_-ar_88200_aac_main_-cutoff_9800_-f_mp4
93 kbps
094
rock.short.wav_-ab_92000_-ar_88200_aac_main_-cutoff_12600_-f_mp4
108 kbps
095
rock.short.wav_-ab_92000_-ar_88200_aac_main_-cutoff_17640_-f_mp4
134 kbps
096
rock.short.wav_-ab_92000_-ar_88200_aac_main_-cutoff_44100_-f_mp4
204 kbps
097 rock.short.wav_-ab_92000_-ar_96000_aac_low_-cutoff_0_-f_mp4
128 kbps
098 rock.short.wav_-ab_92000_-ar_96000_aac_low_-cutoff_960_-f_mp4
33 kbps
099 rock.short.wav_-ab_92000_-ar_96000_aac_low_-cutoff_2400_-f_mp4
62 kbps
100 rock.short.wav_-ab_92000_-ar_96000_aac_low_-cutoff_4800_-f_mp4
92 kbps
101 rock.short.wav_-ab_92000_-ar_96000_aac_low_-cutoff_10666_-f_mp4
99 kbps
102 rock.short.wav_-ab_92000_-ar_96000_aac_low_-cutoff_13714_-f_mp4
115 kbps
103 rock.short.wav_-ab_92000_-ar_96000_aac_low_-cutoff_19200_-f_mp4
143 kbps
104 rock.short.wav_-ab_92000_-ar_96000_aac_low_-cutoff_48000_-f_mp4
220 kbps
105 rock.short.wav_-ab_92000_-ar_96000_aac_ltp_-cutoff_0_-f_mp4
128 kbps
106 rock.short.wav_-ab_92000_-ar_96000_aac_ltp_-cutoff_960_-f_mp4
33 kbps
107 rock.short.wav_-ab_92000_-ar_96000_aac_ltp_-cutoff_2400_-f_mp4
62 kbps
108 rock.short.wav_-ab_92000_-ar_96000_aac_ltp_-cutoff_4800_-f_mp4
92 kbps
109 rock.short.wav_-ab_92000_-ar_96000_aac_ltp_-cutoff_10666_-f_mp4
99 kbps
110 rock.short.wav_-ab_92000_-ar_96000_aac_ltp_-cutoff_13714_-f_mp4
115 kbps
111 rock.short.wav_-ab_92000_-ar_96000_aac_ltp_-cutoff_19200_-f_mp4
143 kbps
112 rock.short.wav_-ab_92000_-ar_96000_aac_ltp_-cutoff_48000_-f_mp4
220 kbps
113 rock.short.wav_-ab_92000_-ar_96000_aac_main_-cutoff_0_-f_mp4
128 kbps
114 rock.short.wav_-ab_92000_-ar_96000_aac_main_-cutoff_960_-f_mp4
33 kbps
115 rock.short.wav_-ab_92000_-ar_96000_aac_main_-cutoff_2400_-f_mp4
62 kbps
116 rock.short.wav_-ab_92000_-ar_96000_aac_main_-cutoff_4800_-f_mp4
92 kbps
117
rock.short.wav_-ab_92000_-ar_96000_aac_main_-cutoff_10666_-f_mp4
99 kbps
118
rock.short.wav_-ab_92000_-ar_96000_aac_main_-cutoff_13714_-f_mp4
116 kbps
119
rock.short.wav_-ab_92000_-ar_96000_aac_main_-cutoff_19200_-f_mp4
143 kbps
120
rock.short.wav_-ab_92000_-ar_96000_aac_main_-cutoff_48000_-f_mp4
220 kbps
121 rock.short.wav_-ab_128000_-ar_22050_aac_low_-cutoff_0_-f_mp4
76 kbps
122 rock.short.wav_-ab_128000_-ar_22050_aac_low_-cutoff_220_-f_mp4
8 kbps
123 rock.short.wav_-ab_128000_-ar_22050_aac_low_-cutoff_551_-f_mp4
14 kbps
124 rock.short.wav_-ab_128000_-ar_22050_aac_low_-cutoff_1102_-f_mp4
24 kbps
125 rock.short.wav_-ab_128000_-ar_22050_aac_low_-cutoff_2450_-f_mp4
47 kbps
126 rock.short.wav_-ab_128000_-ar_22050_aac_low_-cutoff_3150_-f_mp4
58 kbps
127 rock.short.wav_-ab_128000_-ar_22050_aac_low_-cutoff_4410_-f_mp4
75 kbps
128
rock.short.wav_-ab_128000_-ar_22050_aac_low_-cutoff_11025_-f_mp4
128 kbps
129 rock.short.wav_-ab_128000_-ar_22050_aac_ltp_-cutoff_0_-f_mp4
76 kbps
130 rock.short.wav_-ab_128000_-ar_22050_aac_ltp_-cutoff_220_-f_mp4
8 kbps
131 rock.short.wav_-ab_128000_-ar_22050_aac_ltp_-cutoff_551_-f_mp4
14 kbps
132 rock.short.wav_-ab_128000_-ar_22050_aac_ltp_-cutoff_1102_-f_mp4
25 kbps
133 rock.short.wav_-ab_128000_-ar_22050_aac_ltp_-cutoff_2450_-f_mp4
47 kbps
134 rock.short.wav_-ab_128000_-ar_22050_aac_ltp_-cutoff_3150_-f_mp4
58 kbps
135 rock.short.wav_-ab_128000_-ar_22050_aac_ltp_-cutoff_4410_-f_mp4
76 kbps
136
rock.short.wav_-ab_128000_-ar_22050_aac_ltp_-cutoff_11025_-f_mp4
128 kbps
137 rock.short.wav_-ab_128000_-ar_22050_aac_main_-cutoff_0_-f_mp4
76 kbps
138 rock.short.wav_-ab_128000_-ar_22050_aac_main_-cutoff_220_-f_mp4
8 kbps
139 rock.short.wav_-ab_128000_-ar_22050_aac_main_-cutoff_551_-f_mp4
14 kbps
140
rock.short.wav_-ab_128000_-ar_22050_aac_main_-cutoff_1102_-f_mp4
24 kbps
141
rock.short.wav_-ab_128000_-ar_22050_aac_main_-cutoff_2450_-f_mp4
47 kbps
142
rock.short.wav_-ab_128000_-ar_22050_aac_main_-cutoff_3150_-f_mp4
58 kbps
143
rock.short.wav_-ab_128000_-ar_22050_aac_main_-cutoff_4410_-f_mp4
75 kbps
144
rock.short.wav_-ab_128000_-ar_22050_aac_main_-cutoff_11025_-f_mp4
128 kbps
145 rock.short.wav_-ab_128000_-ar_44100_aac_low_-cutoff_0_-f_mp4
128 kbps
146 rock.short.wav_-ab_128000_-ar_44100_aac_low_-cutoff_441_-f_mp4
15 kbps
147 rock.short.wav_-ab_128000_-ar_44100_aac_low_-cutoff_1102_-f_mp4
29 kbps
148 rock.short.wav_-ab_128000_-ar_44100_aac_low_-cutoff_2205_-f_mp4
48 kbps
149 rock.short.wav_-ab_128000_-ar_44100_aac_low_-cutoff_4900_-f_mp4
91 kbps
150 rock.short.wav_-ab_128000_-ar_44100_aac_low_-cutoff_6300_-f_mp4
110 kbps
151 rock.short.wav_-ab_128000_-ar_44100_aac_low_-cutoff_8820_-f_mp4
128 kbps
152
rock.short.wav_-ab_128000_-ar_44100_aac_low_-cutoff_22050_-f_mp4
130 kbps
153 rock.short.wav_-ab_128000_-ar_44100_aac_ltp_-cutoff_0_-f_mp4
128 kbps
154 rock.short.wav_-ab_128000_-ar_44100_aac_ltp_-cutoff_441_-f_mp4
15 kbps
155 rock.short.wav_-ab_128000_-ar_44100_aac_ltp_-cutoff_1102_-f_mp4
29 kbps
156 rock.short.wav_-ab_128000_-ar_44100_aac_ltp_-cutoff_2205_-f_mp4
48 kbps
157 rock.short.wav_-ab_128000_-ar_44100_aac_ltp_-cutoff_4900_-f_mp4
91 kbps
158 rock.short.wav_-ab_128000_-ar_44100_aac_ltp_-cutoff_6300_-f_mp4
111 kbps
159 rock.short.wav_-ab_128000_-ar_44100_aac_ltp_-cutoff_8820_-f_mp4
128 kbps
160
rock.short.wav_-ab_128000_-ar_44100_aac_ltp_-cutoff_22050_-f_mp4
130 kbps
161 rock.short.wav_-ab_128000_-ar_44100_aac_main_-cutoff_0_-f_mp4
128 kbps
162 rock.short.wav_-ab_128000_-ar_44100_aac_main_-cutoff_441_-f_mp4
15 kbps
163
rock.short.wav_-ab_128000_-ar_44100_aac_main_-cutoff_1102_-f_mp4
29 kbps
164
rock.short.wav_-ab_128000_-ar_44100_aac_main_-cutoff_2205_-f_mp4
48 kbps
165
rock.short.wav_-ab_128000_-ar_44100_aac_main_-cutoff_4900_-f_mp4
91 kbps
166
rock.short.wav_-ab_128000_-ar_44100_aac_main_-cutoff_6300_-f_mp4
110 kbps
167
rock.short.wav_-ab_128000_-ar_44100_aac_main_-cutoff_8820_-f_mp4
128 kbps
168
rock.short.wav_-ab_128000_-ar_44100_aac_main_-cutoff_22050_-f_mp4
130 kbps
169 rock.short.wav_-ab_128000_-ar_48000_aac_low_-cutoff_0_-f_mp4
128 kbps
170 rock.short.wav_-ab_128000_-ar_48000_aac_low_-cutoff_480_-f_mp4
17 kbps
171 rock.short.wav_-ab_128000_-ar_48000_aac_low_-cutoff_1200_-f_mp4
31 kbps
172 rock.short.wav_-ab_128000_-ar_48000_aac_low_-cutoff_2400_-f_mp4
52 kbps
173 rock.short.wav_-ab_128000_-ar_48000_aac_low_-cutoff_5333_-f_mp4
98 kbps
174 rock.short.wav_-ab_128000_-ar_48000_aac_low_-cutoff_6857_-f_mp4
118 kbps
175 rock.short.wav_-ab_128000_-ar_48000_aac_low_-cutoff_9600_-f_mp4
128 kbps
176
rock.short.wav_-ab_128000_-ar_48000_aac_low_-cutoff_24000_-f_mp4
133 kbps
177 rock.short.wav_-ab_128000_-ar_48000_aac_ltp_-cutoff_0_-f_mp4
128 kbps
178 rock.short.wav_-ab_128000_-ar_48000_aac_ltp_-cutoff_480_-f_mp4
17 kbps
179 rock.short.wav_-ab_128000_-ar_48000_aac_ltp_-cutoff_1200_-f_mp4
31 kbps
180 rock.short.wav_-ab_128000_-ar_48000_aac_ltp_-cutoff_2400_-f_mp4
52 kbps
181 rock.short.wav_-ab_128000_-ar_48000_aac_ltp_-cutoff_5333_-f_mp4
99 kbps
182 rock.short.wav_-ab_128000_-ar_48000_aac_ltp_-cutoff_6857_-f_mp4
119 kbps
183 rock.short.wav_-ab_128000_-ar_48000_aac_ltp_-cutoff_9600_-f_mp4
128 kbps
184
rock.short.wav_-ab_128000_-ar_48000_aac_ltp_-cutoff_24000_-f_mp4
134 kbps
185 rock.short.wav_-ab_128000_-ar_48000_aac_main_-cutoff_0_-f_mp4
128 kbps
186 rock.short.wav_-ab_128000_-ar_48000_aac_main_-cutoff_480_-f_mp4
17 kbps
187
rock.short.wav_-ab_128000_-ar_48000_aac_main_-cutoff_1200_-f_mp4
31 kbps
188
rock.short.wav_-ab_128000_-ar_48000_aac_main_-cutoff_2400_-f_mp4
52 kbps
189
rock.short.wav_-ab_128000_-ar_48000_aac_main_-cutoff_5333_-f_mp4
98 kbps
190
rock.short.wav_-ab_128000_-ar_48000_aac_main_-cutoff_6857_-f_mp4
119 kbps
191
rock.short.wav_-ab_128000_-ar_48000_aac_main_-cutoff_9600_-f_mp4
128 kbps
192
rock.short.wav_-ab_128000_-ar_48000_aac_main_-cutoff_24000_-f_mp4
134 kbps
193 rock.short.wav_-ab_128000_-ar_88200_aac_low_-cutoff_0_-f_mp4
128 kbps
194 rock.short.wav_-ab_128000_-ar_88200_aac_low_-cutoff_882_-f_mp4
30 kbps
195 rock.short.wav_-ab_128000_-ar_88200_aac_low_-cutoff_2205_-f_mp4
57 kbps
196 rock.short.wav_-ab_128000_-ar_88200_aac_low_-cutoff_4410_-f_mp4
97 kbps
197 rock.short.wav_-ab_128000_-ar_88200_aac_low_-cutoff_9800_-f_mp4
128 kbps
198
rock.short.wav_-ab_128000_-ar_88200_aac_low_-cutoff_12600_-f_mp4
128 kbps
199
rock.short.wav_-ab_128000_-ar_88200_aac_low_-cutoff_17640_-f_mp4
134 kbps
200
rock.short.wav_-ab_128000_-ar_88200_aac_low_-cutoff_44100_-f_mp4
203 kbps
201 rock.short.wav_-ab_128000_-ar_88200_aac_ltp_-cutoff_0_-f_mp4
128 kbps
202 rock.short.wav_-ab_128000_-ar_88200_aac_ltp_-cutoff_882_-f_mp4
30 kbps
203 rock.short.wav_-ab_128000_-ar_88200_aac_ltp_-cutoff_2205_-f_mp4
57 kbps
204 rock.short.wav_-ab_128000_-ar_88200_aac_ltp_-cutoff_4410_-f_mp4
97 kbps
205 rock.short.wav_-ab_128000_-ar_88200_aac_ltp_-cutoff_9800_-f_mp4
128 kbps
206
rock.short.wav_-ab_128000_-ar_88200_aac_ltp_-cutoff_12600_-f_mp4
128 kbps
207
rock.short.wav_-ab_128000_-ar_88200_aac_ltp_-cutoff_17640_-f_mp4
134 kbps
208
rock.short.wav_-ab_128000_-ar_88200_aac_ltp_-cutoff_44100_-f_mp4
204 kbps
209 rock.short.wav_-ab_128000_-ar_88200_aac_main_-cutoff_0_-f_mp4
128 kbps
210 rock.short.wav_-ab_128000_-ar_88200_aac_main_-cutoff_882_-f_mp4
30 kbps
211
rock.short.wav_-ab_128000_-ar_88200_aac_main_-cutoff_2205_-f_mp4
57 kbps
212
rock.short.wav_-ab_128000_-ar_88200_aac_main_-cutoff_4410_-f_mp4
97 kbps
213
rock.short.wav_-ab_128000_-ar_88200_aac_main_-cutoff_9800_-f_mp4
128 kbps
214
rock.short.wav_-ab_128000_-ar_88200_aac_main_-cutoff_12600_-f_mp4
128 kbps
215
rock.short.wav_-ab_128000_-ar_88200_aac_main_-cutoff_17640_-f_mp4
134 kbps
216
rock.short.wav_-ab_128000_-ar_88200_aac_main_-cutoff_44100_-f_mp4
204 kbps
217 rock.short.wav_-ab_128000_-ar_96000_aac_low_-cutoff_0_-f_mp4
128 kbps
218 rock.short.wav_-ab_128000_-ar_96000_aac_low_-cutoff_960_-f_mp4
33 kbps
219 rock.short.wav_-ab_128000_-ar_96000_aac_low_-cutoff_2400_-f_mp4
62 kbps
220 rock.short.wav_-ab_128000_-ar_96000_aac_low_-cutoff_4800_-f_mp4
105 kbps
221
rock.short.wav_-ab_128000_-ar_96000_aac_low_-cutoff_10666_-f_mp4
128 kbps
222
rock.short.wav_-ab_128000_-ar_96000_aac_low_-cutoff_13714_-f_mp4
128 kbps
223
rock.short.wav_-ab_128000_-ar_96000_aac_low_-cutoff_19200_-f_mp4
143 kbps
224
rock.short.wav_-ab_128000_-ar_96000_aac_low_-cutoff_48000_-f_mp4
220 kbps
225 rock.short.wav_-ab_128000_-ar_96000_aac_ltp_-cutoff_0_-f_mp4
128 kbps
226 rock.short.wav_-ab_128000_-ar_96000_aac_ltp_-cutoff_960_-f_mp4
33 kbps
227 rock.short.wav_-ab_128000_-ar_96000_aac_ltp_-cutoff_2400_-f_mp4
62 kbps
228 rock.short.wav_-ab_128000_-ar_96000_aac_ltp_-cutoff_4800_-f_mp4
105 kbps
229
rock.short.wav_-ab_128000_-ar_96000_aac_ltp_-cutoff_10666_-f_mp4
128 kbps
230
rock.short.wav_-ab_128000_-ar_96000_aac_ltp_-cutoff_13714_-f_mp4
128 kbps
231
rock.short.wav_-ab_128000_-ar_96000_aac_ltp_-cutoff_19200_-f_mp4
143 kbps
232
rock.short.wav_-ab_128000_-ar_96000_aac_ltp_-cutoff_48000_-f_mp4
220 kbps
233 rock.short.wav_-ab_128000_-ar_96000_aac_main_-cutoff_0_-f_mp4
128 kbps
234 rock.short.wav_-ab_128000_-ar_96000_aac_main_-cutoff_960_-f_mp4
33 kbps
235
rock.short.wav_-ab_128000_-ar_96000_aac_main_-cutoff_2400_-f_mp4
62 kbps
236
rock.short.wav_-ab_128000_-ar_96000_aac_main_-cutoff_4800_-f_mp4
106 kbps
237
rock.short.wav_-ab_128000_-ar_96000_aac_main_-cutoff_10666_-f_mp4
128 kbps
238
rock.short.wav_-ab_128000_-ar_96000_aac_main_-cutoff_13714_-f_mp4
128 kbps
239
rock.short.wav_-ab_128000_-ar_96000_aac_main_-cutoff_19200_-f_mp4
143 kbps
240
rock.short.wav_-ab_128000_-ar_96000_aac_main_-cutoff_48000_-f_mp4
220 kbps
241 rock.short.wav_-ab_192000_-ar_22050_aac_low_-cutoff_0_-f_mp4
76 kbps
242 rock.short.wav_-ab_192000_-ar_22050_aac_low_-cutoff_220_-f_mp4
8 kbps
243 rock.short.wav_-ab_192000_-ar_22050_aac_low_-cutoff_551_-f_mp4
14 kbps
244 rock.short.wav_-ab_192000_-ar_22050_aac_low_-cutoff_1102_-f_mp4
24 kbps
245 rock.short.wav_-ab_192000_-ar_22050_aac_low_-cutoff_2450_-f_mp4
47 kbps
246 rock.short.wav_-ab_192000_-ar_22050_aac_low_-cutoff_3150_-f_mp4
58 kbps
247 rock.short.wav_-ab_192000_-ar_22050_aac_low_-cutoff_4410_-f_mp4
75 kbps
248
rock.short.wav_-ab_192000_-ar_22050_aac_low_-cutoff_11025_-f_mp4
147 kbps
249 rock.short.wav_-ab_192000_-ar_22050_aac_ltp_-cutoff_0_-f_mp4
76 kbps
250 rock.short.wav_-ab_192000_-ar_22050_aac_ltp_-cutoff_220_-f_mp4
8 kbps
251 rock.short.wav_-ab_192000_-ar_22050_aac_ltp_-cutoff_551_-f_mp4
14 kbps
252 rock.short.wav_-ab_192000_-ar_22050_aac_ltp_-cutoff_1102_-f_mp4
25 kbps
253 rock.short.wav_-ab_192000_-ar_22050_aac_ltp_-cutoff_2450_-f_mp4
47 kbps
254 rock.short.wav_-ab_192000_-ar_22050_aac_ltp_-cutoff_3150_-f_mp4
58 kbps
255 rock.short.wav_-ab_192000_-ar_22050_aac_ltp_-cutoff_4410_-f_mp4
76 kbps
256
rock.short.wav_-ab_192000_-ar_22050_aac_ltp_-cutoff_11025_-f_mp4
148 kbps
257 rock.short.wav_-ab_192000_-ar_22050_aac_main_-cutoff_0_-f_mp4
76 kbps
258 rock.short.wav_-ab_192000_-ar_22050_aac_main_-cutoff_220_-f_mp4
8 kbps
259 rock.short.wav_-ab_192000_-ar_22050_aac_main_-cutoff_551_-f_mp4
14 kbps
260
rock.short.wav_-ab_192000_-ar_22050_aac_main_-cutoff_1102_-f_mp4
24 kbps
261
rock.short.wav_-ab_192000_-ar_22050_aac_main_-cutoff_2450_-f_mp4
47 kbps
262
rock.short.wav_-ab_192000_-ar_22050_aac_main_-cutoff_3150_-f_mp4
58 kbps
263
rock.short.wav_-ab_192000_-ar_22050_aac_main_-cutoff_4410_-f_mp4
75 kbps
264
rock.short.wav_-ab_192000_-ar_22050_aac_main_-cutoff_11025_-f_mp4
147 kbps
265 rock.short.wav_-ab_192000_-ar_44100_aac_low_-cutoff_0_-f_mp4
152 kbps
266 rock.short.wav_-ab_192000_-ar_44100_aac_low_-cutoff_441_-f_mp4
15 kbps
267 rock.short.wav_-ab_192000_-ar_44100_aac_low_-cutoff_1102_-f_mp4
29 kbps
268 rock.short.wav_-ab_192000_-ar_44100_aac_low_-cutoff_2205_-f_mp4
48 kbps
269 rock.short.wav_-ab_192000_-ar_44100_aac_low_-cutoff_4900_-f_mp4
91 kbps
270 rock.short.wav_-ab_192000_-ar_44100_aac_low_-cutoff_6300_-f_mp4
110 kbps
271 rock.short.wav_-ab_192000_-ar_44100_aac_low_-cutoff_8820_-f_mp4
138 kbps
272
rock.short.wav_-ab_192000_-ar_44100_aac_low_-cutoff_22050_-f_mp4
192 kbps
273 rock.short.wav_-ab_192000_-ar_44100_aac_ltp_-cutoff_0_-f_mp4
152 kbps
274 rock.short.wav_-ab_192000_-ar_44100_aac_ltp_-cutoff_441_-f_mp4
15 kbps
275 rock.short.wav_-ab_192000_-ar_44100_aac_ltp_-cutoff_1102_-f_mp4
29 kbps
276 rock.short.wav_-ab_192000_-ar_44100_aac_ltp_-cutoff_2205_-f_mp4
48 kbps
277 rock.short.wav_-ab_192000_-ar_44100_aac_ltp_-cutoff_4900_-f_mp4
91 kbps
278 rock.short.wav_-ab_192000_-ar_44100_aac_ltp_-cutoff_6300_-f_mp4
111 kbps
279 rock.short.wav_-ab_192000_-ar_44100_aac_ltp_-cutoff_8820_-f_mp4
139 kbps
280
rock.short.wav_-ab_192000_-ar_44100_aac_ltp_-cutoff_22050_-f_mp4
192 kbps
281 rock.short.wav_-ab_192000_-ar_44100_aac_main_-cutoff_0_-f_mp4
152 kbps
282 rock.short.wav_-ab_192000_-ar_44100_aac_main_-cutoff_441_-f_mp4
15 kbps
283
rock.short.wav_-ab_192000_-ar_44100_aac_main_-cutoff_1102_-f_mp4
29 kbps
284
rock.short.wav_-ab_192000_-ar_44100_aac_main_-cutoff_2205_-f_mp4
48 kbps
285
rock.short.wav_-ab_192000_-ar_44100_aac_main_-cutoff_4900_-f_mp4
91 kbps
286
rock.short.wav_-ab_192000_-ar_44100_aac_main_-cutoff_6300_-f_mp4
110 kbps
287
rock.short.wav_-ab_192000_-ar_44100_aac_main_-cutoff_8820_-f_mp4
139 kbps
288
rock.short.wav_-ab_192000_-ar_44100_aac_main_-cutoff_22050_-f_mp4
192 kbps
289 rock.short.wav_-ab_192000_-ar_48000_aac_low_-cutoff_0_-f_mp4
165 kbps
290 rock.short.wav_-ab_192000_-ar_48000_aac_low_-cutoff_480_-f_mp4
17 kbps
291 rock.short.wav_-ab_192000_-ar_48000_aac_low_-cutoff_1200_-f_mp4
31 kbps
292 rock.short.wav_-ab_192000_-ar_48000_aac_low_-cutoff_2400_-f_mp4
52 kbps
293 rock.short.wav_-ab_192000_-ar_48000_aac_low_-cutoff_5333_-f_mp4
98 kbps
294 rock.short.wav_-ab_192000_-ar_48000_aac_low_-cutoff_6857_-f_mp4
118 kbps
295 rock.short.wav_-ab_192000_-ar_48000_aac_low_-cutoff_9600_-f_mp4
149 kbps
296
rock.short.wav_-ab_192000_-ar_48000_aac_low_-cutoff_24000_-f_mp4
192 kbps
297 rock.short.wav_-ab_192000_-ar_48000_aac_ltp_-cutoff_0_-f_mp4
165 kbps
298 rock.short.wav_-ab_192000_-ar_48000_aac_ltp_-cutoff_480_-f_mp4
17 kbps
299 rock.short.wav_-ab_192000_-ar_48000_aac_ltp_-cutoff_1200_-f_mp4
31 kbps
300 rock.short.wav_-ab_192000_-ar_48000_aac_ltp_-cutoff_2400_-f_mp4
52 kbps
301 rock.short.wav_-ab_192000_-ar_48000_aac_ltp_-cutoff_5333_-f_mp4
99 kbps
302 rock.short.wav_-ab_192000_-ar_48000_aac_ltp_-cutoff_6857_-f_mp4
119 kbps
303 rock.short.wav_-ab_192000_-ar_48000_aac_ltp_-cutoff_9600_-f_mp4
150 kbps
304
rock.short.wav_-ab_192000_-ar_48000_aac_ltp_-cutoff_24000_-f_mp4
192 kbps
305 rock.short.wav_-ab_192000_-ar_48000_aac_main_-cutoff_0_-f_mp4
165 kbps
306 rock.short.wav_-ab_192000_-ar_48000_aac_main_-cutoff_480_-f_mp4
17 kbps
307
rock.short.wav_-ab_192000_-ar_48000_aac_main_-cutoff_1200_-f_mp4
31 kbps
308
rock.short.wav_-ab_192000_-ar_48000_aac_main_-cutoff_2400_-f_mp4
52 kbps
309
rock.short.wav_-ab_192000_-ar_48000_aac_main_-cutoff_5333_-f_mp4
98 kbps
310
rock.short.wav_-ab_192000_-ar_48000_aac_main_-cutoff_6857_-f_mp4
119 kbps
311
rock.short.wav_-ab_192000_-ar_48000_aac_main_-cutoff_9600_-f_mp4
149 kbps
312
rock.short.wav_-ab_192000_-ar_48000_aac_main_-cutoff_24000_-f_mp4
192 kbps
313 rock.short.wav_-ab_192000_-ar_88200_aac_low_-cutoff_0_-f_mp4
192 kbps
314 rock.short.wav_-ab_192000_-ar_88200_aac_low_-cutoff_882_-f_mp4
30 kbps
315 rock.short.wav_-ab_192000_-ar_88200_aac_low_-cutoff_2205_-f_mp4
57 kbps
316 rock.short.wav_-ab_192000_-ar_88200_aac_low_-cutoff_4410_-f_mp4
97 kbps
317 rock.short.wav_-ab_192000_-ar_88200_aac_low_-cutoff_9800_-f_mp4
170 kbps
318
rock.short.wav_-ab_192000_-ar_88200_aac_low_-cutoff_12600_-f_mp4
192 kbps
319
rock.short.wav_-ab_192000_-ar_88200_aac_low_-cutoff_17640_-f_mp4
192 kbps
320
rock.short.wav_-ab_192000_-ar_88200_aac_low_-cutoff_44100_-f_mp4
204 kbps
321 rock.short.wav_-ab_192000_-ar_88200_aac_ltp_-cutoff_0_-f_mp4
192 kbps
322 rock.short.wav_-ab_192000_-ar_88200_aac_ltp_-cutoff_882_-f_mp4
30 kbps
323 rock.short.wav_-ab_192000_-ar_88200_aac_ltp_-cutoff_2205_-f_mp4
57 kbps
324 rock.short.wav_-ab_192000_-ar_88200_aac_ltp_-cutoff_4410_-f_mp4
97 kbps
325 rock.short.wav_-ab_192000_-ar_88200_aac_ltp_-cutoff_9800_-f_mp4
170 kbps
326
rock.short.wav_-ab_192000_-ar_88200_aac_ltp_-cutoff_12600_-f_mp4
192 kbps
327
rock.short.wav_-ab_192000_-ar_88200_aac_ltp_-cutoff_17640_-f_mp4
192 kbps
328
rock.short.wav_-ab_192000_-ar_88200_aac_ltp_-cutoff_44100_-f_mp4
204 kbps
329 rock.short.wav_-ab_192000_-ar_88200_aac_main_-cutoff_0_-f_mp4
192 kbps
330 rock.short.wav_-ab_192000_-ar_88200_aac_main_-cutoff_882_-f_mp4
30 kbps
331
rock.short.wav_-ab_192000_-ar_88200_aac_main_-cutoff_2205_-f_mp4
57 kbps
332
rock.short.wav_-ab_192000_-ar_88200_aac_main_-cutoff_4410_-f_mp4
97 kbps
333
rock.short.wav_-ab_192000_-ar_88200_aac_main_-cutoff_9800_-f_mp4
170 kbps
334
rock.short.wav_-ab_192000_-ar_88200_aac_main_-cutoff_12600_-f_mp4
192 kbps
335
rock.short.wav_-ab_192000_-ar_88200_aac_main_-cutoff_17640_-f_mp4
192 kbps
336
rock.short.wav_-ab_192000_-ar_88200_aac_main_-cutoff_44100_-f_mp4
204 kbps
337 rock.short.wav_-ab_192000_-ar_96000_aac_low_-cutoff_0_-f_mp4
192 kbps
338 rock.short.wav_-ab_192000_-ar_96000_aac_low_-cutoff_960_-f_mp4
33 kbps
339 rock.short.wav_-ab_192000_-ar_96000_aac_low_-cutoff_2400_-f_mp4
62 kbps
340 rock.short.wav_-ab_192000_-ar_96000_aac_low_-cutoff_4800_-f_mp4
105 kbps
341
rock.short.wav_-ab_192000_-ar_96000_aac_low_-cutoff_10666_-f_mp4
184 kbps
342
rock.short.wav_-ab_192000_-ar_96000_aac_low_-cutoff_13714_-f_mp4
192 kbps
343
rock.short.wav_-ab_192000_-ar_96000_aac_low_-cutoff_19200_-f_mp4
192 kbps
344
rock.short.wav_-ab_192000_-ar_96000_aac_low_-cutoff_48000_-f_mp4
220 kbps
345 rock.short.wav_-ab_192000_-ar_96000_aac_ltp_-cutoff_0_-f_mp4
192 kbps
346 rock.short.wav_-ab_192000_-ar_96000_aac_ltp_-cutoff_960_-f_mp4
33 kbps
347 rock.short.wav_-ab_192000_-ar_96000_aac_ltp_-cutoff_2400_-f_mp4
62 kbps
348 rock.short.wav_-ab_192000_-ar_96000_aac_ltp_-cutoff_4800_-f_mp4
105 kbps
349
rock.short.wav_-ab_192000_-ar_96000_aac_ltp_-cutoff_10666_-f_mp4
184 kbps
350
rock.short.wav_-ab_192000_-ar_96000_aac_ltp_-cutoff_13714_-f_mp4
192 kbps
351
rock.short.wav_-ab_192000_-ar_96000_aac_ltp_-cutoff_19200_-f_mp4
192 kbps
352
rock.short.wav_-ab_192000_-ar_96000_aac_ltp_-cutoff_48000_-f_mp4
220 kbps
353 rock.short.wav_-ab_192000_-ar_96000_aac_main_-cutoff_0_-f_mp4
192 kbps
354 rock.short.wav_-ab_192000_-ar_96000_aac_main_-cutoff_960_-f_mp4
33 kbps
355
rock.short.wav_-ab_192000_-ar_96000_aac_main_-cutoff_2400_-f_mp4
62 kbps
356
rock.short.wav_-ab_192000_-ar_96000_aac_main_-cutoff_4800_-f_mp4
106 kbps
357
rock.short.wav_-ab_192000_-ar_96000_aac_main_-cutoff_10666_-f_mp4
184 kbps
358
rock.short.wav_-ab_192000_-ar_96000_aac_main_-cutoff_13714_-f_mp4
192 kbps
359
rock.short.wav_-ab_192000_-ar_96000_aac_main_-cutoff_19200_-f_mp4
192 kbps
360
rock.short.wav_-ab_192000_-ar_96000_aac_main_-cutoff_48000_-f_mp4
220 kbps
361 rock.short.wav_-ab_256000_-ar_22050_aac_low_-cutoff_0_-f_mp4
76 kbps
362 rock.short.wav_-ab_256000_-ar_22050_aac_low_-cutoff_220_-f_mp4
8 kbps
363 rock.short.wav_-ab_256000_-ar_22050_aac_low_-cutoff_551_-f_mp4
14 kbps
364 rock.short.wav_-ab_256000_-ar_22050_aac_low_-cutoff_1102_-f_mp4
24 kbps
365 rock.short.wav_-ab_256000_-ar_22050_aac_low_-cutoff_2450_-f_mp4
47 kbps
366 rock.short.wav_-ab_256000_-ar_22050_aac_low_-cutoff_3150_-f_mp4
58 kbps
367 rock.short.wav_-ab_256000_-ar_22050_aac_low_-cutoff_4410_-f_mp4
75 kbps
368
rock.short.wav_-ab_256000_-ar_22050_aac_low_-cutoff_11025_-f_mp4
147 kbps
369 rock.short.wav_-ab_256000_-ar_22050_aac_ltp_-cutoff_0_-f_mp4
76 kbps
370 rock.short.wav_-ab_256000_-ar_22050_aac_ltp_-cutoff_220_-f_mp4
8 kbps
371 rock.short.wav_-ab_256000_-ar_22050_aac_ltp_-cutoff_551_-f_mp4
14 kbps
372 rock.short.wav_-ab_256000_-ar_22050_aac_ltp_-cutoff_1102_-f_mp4
25 kbps
373 rock.short.wav_-ab_256000_-ar_22050_aac_ltp_-cutoff_2450_-f_mp4
47 kbps
374 rock.short.wav_-ab_256000_-ar_22050_aac_ltp_-cutoff_3150_-f_mp4
58 kbps
375 rock.short.wav_-ab_256000_-ar_22050_aac_ltp_-cutoff_4410_-f_mp4
76 kbps
376
rock.short.wav_-ab_256000_-ar_22050_aac_ltp_-cutoff_11025_-f_mp4
148 kbps
377 rock.short.wav_-ab_256000_-ar_22050_aac_main_-cutoff_0_-f_mp4
76 kbps
378 rock.short.wav_-ab_256000_-ar_22050_aac_main_-cutoff_220_-f_mp4
8 kbps
379 rock.short.wav_-ab_256000_-ar_22050_aac_main_-cutoff_551_-f_mp4
14 kbps
380
rock.short.wav_-ab_256000_-ar_22050_aac_main_-cutoff_1102_-f_mp4
24 kbps
381
rock.short.wav_-ab_256000_-ar_22050_aac_main_-cutoff_2450_-f_mp4
47 kbps
382
rock.short.wav_-ab_256000_-ar_22050_aac_main_-cutoff_3150_-f_mp4
58 kbps
383
rock.short.wav_-ab_256000_-ar_22050_aac_main_-cutoff_4410_-f_mp4
75 kbps
384
rock.short.wav_-ab_256000_-ar_22050_aac_main_-cutoff_11025_-f_mp4
147 kbps
385 rock.short.wav_-ab_256000_-ar_44100_aac_low_-cutoff_0_-f_mp4
152 kbps
386 rock.short.wav_-ab_256000_-ar_44100_aac_low_-cutoff_441_-f_mp4
15 kbps
387 rock.short.wav_-ab_256000_-ar_44100_aac_low_-cutoff_1102_-f_mp4
29 kbps
388 rock.short.wav_-ab_256000_-ar_44100_aac_low_-cutoff_2205_-f_mp4
48 kbps
389 rock.short.wav_-ab_256000_-ar_44100_aac_low_-cutoff_4900_-f_mp4
91 kbps
390 rock.short.wav_-ab_256000_-ar_44100_aac_low_-cutoff_6300_-f_mp4
110 kbps
391 rock.short.wav_-ab_256000_-ar_44100_aac_low_-cutoff_8820_-f_mp4
138 kbps
392
rock.short.wav_-ab_256000_-ar_44100_aac_low_-cutoff_22050_-f_mp4
256 kbps
393 rock.short.wav_-ab_256000_-ar_44100_aac_ltp_-cutoff_0_-f_mp4
152 kbps
394 rock.short.wav_-ab_256000_-ar_44100_aac_ltp_-cutoff_441_-f_mp4
15 kbps
395 rock.short.wav_-ab_256000_-ar_44100_aac_ltp_-cutoff_1102_-f_mp4
29 kbps
396 rock.short.wav_-ab_256000_-ar_44100_aac_ltp_-cutoff_2205_-f_mp4
48 kbps
397 rock.short.wav_-ab_256000_-ar_44100_aac_ltp_-cutoff_4900_-f_mp4
91 kbps
398 rock.short.wav_-ab_256000_-ar_44100_aac_ltp_-cutoff_6300_-f_mp4
111 kbps
399 rock.short.wav_-ab_256000_-ar_44100_aac_ltp_-cutoff_8820_-f_mp4
139 kbps
400
rock.short.wav_-ab_256000_-ar_44100_aac_ltp_-cutoff_22050_-f_mp4
256 kbps
401 rock.short.wav_-ab_256000_-ar_44100_aac_main_-cutoff_0_-f_mp4
152 kbps
402 rock.short.wav_-ab_256000_-ar_44100_aac_main_-cutoff_441_-f_mp4
15 kbps
403
rock.short.wav_-ab_256000_-ar_44100_aac_main_-cutoff_1102_-f_mp4
29 kbps
404
rock.short.wav_-ab_256000_-ar_44100_aac_main_-cutoff_2205_-f_mp4
48 kbps
405
rock.short.wav_-ab_256000_-ar_44100_aac_main_-cutoff_4900_-f_mp4
91 kbps
406
rock.short.wav_-ab_256000_-ar_44100_aac_main_-cutoff_6300_-f_mp4
110 kbps
407
rock.short.wav_-ab_256000_-ar_44100_aac_main_-cutoff_8820_-f_mp4
139 kbps
408
rock.short.wav_-ab_256000_-ar_44100_aac_main_-cutoff_22050_-f_mp4
256 kbps
409 rock.short.wav_-ab_256000_-ar_48000_aac_low_-cutoff_0_-f_mp4
165 kbps
410 rock.short.wav_-ab_256000_-ar_48000_aac_low_-cutoff_480_-f_mp4
17 kbps
411 rock.short.wav_-ab_256000_-ar_48000_aac_low_-cutoff_1200_-f_mp4
31 kbps
412 rock.short.wav_-ab_256000_-ar_48000_aac_low_-cutoff_2400_-f_mp4
52 kbps
413 rock.short.wav_-ab_256000_-ar_48000_aac_low_-cutoff_5333_-f_mp4
98 kbps
414 rock.short.wav_-ab_256000_-ar_48000_aac_low_-cutoff_6857_-f_mp4
118 kbps
415 rock.short.wav_-ab_256000_-ar_48000_aac_low_-cutoff_9600_-f_mp4
149 kbps
416
rock.short.wav_-ab_256000_-ar_48000_aac_low_-cutoff_24000_-f_mp4
256 kbps
417 rock.short.wav_-ab_256000_-ar_48000_aac_ltp_-cutoff_0_-f_mp4
165 kbps
418 rock.short.wav_-ab_256000_-ar_48000_aac_ltp_-cutoff_480_-f_mp4
17 kbps
419 rock.short.wav_-ab_256000_-ar_48000_aac_ltp_-cutoff_1200_-f_mp4
31 kbps
420 rock.short.wav_-ab_256000_-ar_48000_aac_ltp_-cutoff_2400_-f_mp4
52 kbps
421 rock.short.wav_-ab_256000_-ar_48000_aac_ltp_-cutoff_5333_-f_mp4
99 kbps
422 rock.short.wav_-ab_256000_-ar_48000_aac_ltp_-cutoff_6857_-f_mp4
119 kbps
423 rock.short.wav_-ab_256000_-ar_48000_aac_ltp_-cutoff_9600_-f_mp4
150 kbps
424
rock.short.wav_-ab_256000_-ar_48000_aac_ltp_-cutoff_24000_-f_mp4
256 kbps
425 rock.short.wav_-ab_256000_-ar_48000_aac_main_-cutoff_0_-f_mp4
165 kbps
426 rock.short.wav_-ab_256000_-ar_48000_aac_main_-cutoff_480_-f_mp4
17 kbps
427
rock.short.wav_-ab_256000_-ar_48000_aac_main_-cutoff_1200_-f_mp4
31 kbps
428
rock.short.wav_-ab_256000_-ar_48000_aac_main_-cutoff_2400_-f_mp4
52 kbps
429
rock.short.wav_-ab_256000_-ar_48000_aac_main_-cutoff_5333_-f_mp4
98 kbps
430
rock.short.wav_-ab_256000_-ar_48000_aac_main_-cutoff_6857_-f_mp4
119 kbps
431
rock.short.wav_-ab_256000_-ar_48000_aac_main_-cutoff_9600_-f_mp4
149 kbps
432
rock.short.wav_-ab_256000_-ar_48000_aac_main_-cutoff_24000_-f_mp4
256 kbps
433 rock.short.wav_-ab_256000_-ar_88200_aac_low_-cutoff_0_-f_mp4
239 kbps
434 rock.short.wav_-ab_256000_-ar_88200_aac_low_-cutoff_882_-f_mp4
30 kbps
435 rock.short.wav_-ab_256000_-ar_88200_aac_low_-cutoff_2205_-f_mp4
57 kbps
436 rock.short.wav_-ab_256000_-ar_88200_aac_low_-cutoff_4410_-f_mp4
97 kbps
437 rock.short.wav_-ab_256000_-ar_88200_aac_low_-cutoff_9800_-f_mp4
170 kbps
438
rock.short.wav_-ab_256000_-ar_88200_aac_low_-cutoff_12600_-f_mp4
205 kbps
439
rock.short.wav_-ab_256000_-ar_88200_aac_low_-cutoff_17640_-f_mp4
256 kbps
440
rock.short.wav_-ab_256000_-ar_88200_aac_low_-cutoff_44100_-f_mp4
256 kbps
441 rock.short.wav_-ab_256000_-ar_88200_aac_ltp_-cutoff_0_-f_mp4
239 kbps
442 rock.short.wav_-ab_256000_-ar_88200_aac_ltp_-cutoff_882_-f_mp4
30 kbps
443 rock.short.wav_-ab_256000_-ar_88200_aac_ltp_-cutoff_2205_-f_mp4
57 kbps
444 rock.short.wav_-ab_256000_-ar_88200_aac_ltp_-cutoff_4410_-f_mp4
97 kbps
445 rock.short.wav_-ab_256000_-ar_88200_aac_ltp_-cutoff_9800_-f_mp4
170 kbps
446
rock.short.wav_-ab_256000_-ar_88200_aac_ltp_-cutoff_12600_-f_mp4
205 kbps
447
rock.short.wav_-ab_256000_-ar_88200_aac_ltp_-cutoff_17640_-f_mp4
256 kbps
448
rock.short.wav_-ab_256000_-ar_88200_aac_ltp_-cutoff_44100_-f_mp4
256 kbps
449 rock.short.wav_-ab_256000_-ar_88200_aac_main_-cutoff_0_-f_mp4
239 kbps
450 rock.short.wav_-ab_256000_-ar_88200_aac_main_-cutoff_882_-f_mp4
30 kbps
451
rock.short.wav_-ab_256000_-ar_88200_aac_main_-cutoff_2205_-f_mp4
57 kbps
452
rock.short.wav_-ab_256000_-ar_88200_aac_main_-cutoff_4410_-f_mp4
97 kbps
453
rock.short.wav_-ab_256000_-ar_88200_aac_main_-cutoff_9800_-f_mp4
170 kbps
454
rock.short.wav_-ab_256000_-ar_88200_aac_main_-cutoff_12600_-f_mp4
205 kbps
455
rock.short.wav_-ab_256000_-ar_88200_aac_main_-cutoff_17640_-f_mp4
256 kbps
456
rock.short.wav_-ab_256000_-ar_88200_aac_main_-cutoff_44100_-f_mp4
256 kbps
457 rock.short.wav_-ab_256000_-ar_96000_aac_low_-cutoff_0_-f_mp4
250 kbps
458 rock.short.wav_-ab_256000_-ar_96000_aac_low_-cutoff_960_-f_mp4
33 kbps
459 rock.short.wav_-ab_256000_-ar_96000_aac_low_-cutoff_2400_-f_mp4
62 kbps
460 rock.short.wav_-ab_256000_-ar_96000_aac_low_-cutoff_4800_-f_mp4
105 kbps
461
rock.short.wav_-ab_256000_-ar_96000_aac_low_-cutoff_10666_-f_mp4
184 kbps
462
rock.short.wav_-ab_256000_-ar_96000_aac_low_-cutoff_13714_-f_mp4
221 kbps
463
rock.short.wav_-ab_256000_-ar_96000_aac_low_-cutoff_19200_-f_mp4
256 kbps
464
rock.short.wav_-ab_256000_-ar_96000_aac_low_-cutoff_48000_-f_mp4
256 kbps
465 rock.short.wav_-ab_256000_-ar_96000_aac_ltp_-cutoff_0_-f_mp4
250 kbps
466 rock.short.wav_-ab_256000_-ar_96000_aac_ltp_-cutoff_960_-f_mp4
33 kbps
467 rock.short.wav_-ab_256000_-ar_96000_aac_ltp_-cutoff_2400_-f_mp4
62 kbps
468 rock.short.wav_-ab_256000_-ar_96000_aac_ltp_-cutoff_4800_-f_mp4
105 kbps
469
rock.short.wav_-ab_256000_-ar_96000_aac_ltp_-cutoff_10666_-f_mp4
184 kbps
470
rock.short.wav_-ab_256000_-ar_96000_aac_ltp_-cutoff_13714_-f_mp4
221 kbps
471
rock.short.wav_-ab_256000_-ar_96000_aac_ltp_-cutoff_19200_-f_mp4
256 kbps
472
rock.short.wav_-ab_256000_-ar_96000_aac_ltp_-cutoff_48000_-f_mp4
256 kbps
473 rock.short.wav_-ab_256000_-ar_96000_aac_main_-cutoff_0_-f_mp4
250 kbps
474 rock.short.wav_-ab_256000_-ar_96000_aac_main_-cutoff_960_-f_mp4
33 kbps
475
rock.short.wav_-ab_256000_-ar_96000_aac_main_-cutoff_2400_-f_mp4
62 kbps
476
rock.short.wav_-ab_256000_-ar_96000_aac_main_-cutoff_4800_-f_mp4
106 kbps
477
rock.short.wav_-ab_256000_-ar_96000_aac_main_-cutoff_10666_-f_mp4
184 kbps
478
rock.short.wav_-ab_256000_-ar_96000_aac_main_-cutoff_13714_-f_mp4
221 kbps
479
rock.short.wav_-ab_256000_-ar_96000_aac_main_-cutoff_19200_-f_mp4
256 kbps
480
rock.short.wav_-ab_256000_-ar_96000_aac_main_-cutoff_48000_-f_mp4
256 kbps

Remember, that this was done using ffmpeg, and it's -ab setting sets up
the bitrate for the whole file (unlike Audacity, which sets up the
bitrate per channel). Obviously, both -ab, -ar and -cutoff have
influence on the outcome: wider bandwidth -> more opportunities to
achieve higher bitrate (and using too wide bandwidth results in
overshot, as codec has to use more bitrate that it was allowed by user).
Bandwidth == Cutoff frequency. Which, in turn, can't be more than one
half of Sample Rate.

I tweaked the calculating process by dividing selected sample rate by
two for the purpose of calculating maximum bitrate (that gives us max
129 kbit/s per channel for 44100 - more than enough, if you ask me), and
resulting file will have almost precisely the desired bitrate -
deviations will only occur for lowest bitrates (in case of 44100 Hz and
my sample audio file it was around 48 kbit/s per channel). I tested it
without a tweak - maximum per-channel bitrate in this case is 135
kbit/s, so 129 kbit/s seems a pretty good guess. For 22050Hz it is 151
kbit/s real maximum (which is ~76 kbit/s per channel) vs calculated (in
tweaked version) 64 kbit/s per channel - again, pretty close guess. So,
unless people start exporting audio in weird sample rates this tweaked
verison calculates correct maximum bitrate per channel.
SampleRate/2 cutoff frequency is still used, of course. By the way it's
funny to try to encode audio with LOW cutoff - like 1000Hz. It results
in extremely muffled sound - it cuts off all the high frequencies,
leaving only low ones. As if i'm listening through a thick wall or
messed with equalizer bass preset too much...

Unplayability of mp4 files were caused by my "black magic" patch, i
apologise. I removed it, since it was half-correct anyways (regardless
of any mistakes i made in comparison functions) - valid extensions are:
mp4, mov, 3gp and m4a. For ipod, psp, etc the mp4 extension is used.
Because of that i'm reverting back to simple "mp4" and "rename if you
need mov/3gp/etc". I think "default extension" facility is due, but that
is the story for another day (and i don't see how it could be useful for
non-aac files).
Richard Ash
2008-07-19 16:23:27 UTC
Permalink
Post by LRN
I installed iTunes again and made a couple of tests. I am positive that
iTunes v7.7.0.43 is unable to play MP4/MOV/etc AAC files, encoded by
ffmpeg (using ffmpeg.exe -i file.wav -acodec libfaac -ar xxx -ab yyy
-cutoff zzz -f fmt file.mp4 or similar commandline; ffmpeg of version
git-c83671b at 11 June 2008), unless it's LC-AAC.
In which case, I think we should add something to the list of options in
the drop-down list - so it reads Low Complexity (Default), Main, LTP or
so.
Post by LRN
Remember, that this was done using ffmpeg, and it's -ab setting sets up
the bitrate for the whole file (unlike Audacity, which sets up the
bitrate per channel). Obviously, both -ab, -ar and -cutoff have
influence on the outcome: wider bandwidth -> more opportunities to
achieve higher bitrate (and using too wide bandwidth results in
overshot, as codec has to use more bitrate that it was allowed by user).
Bandwidth == Cutoff frequency. Which, in turn, can't be more than one
half of Sample Rate.
How weird. With most other codecs there are two possible modes -
quantiser controlled and bitrate controlled.

In a a quantiser controlled configuration, the amount of information
thrown away is fixed. The bit rate is essentially unpredictable,
determined by the content in the input data. This is basically the
"easy" mode for codec writers, because they just set the parameters and
let the algorithm get on with it.

In a bitrate controlled system the amount of information thrown away is
adjusted to keep the bit rate of the file at a constant level. This
usually means a feedback loop that watches the bit rate of the output
and fiddles with the encoding settings to keep the bit rate under
control. Various tweaks are employed to allow short-term peaks in the
bit rate due to complex data without the long-term bit rate going out of
control.

The high frequency roll-off control is unusual to have as a codec
setting, although for almost any codec rolling off the high frequency
content will make the input simpler and easier to encode, allowing a
constant quantiser system to do lower bitrates, and a constant bit rate
system to have fewer artifacts. The cost is the complete loss of the HF
information cut off - but on many budget systems they are inaudible
anyway.

In theory it is always better to lower the sample rate of the recording
to remove excess HF content, because this actually reduces the
uncompressed data rate as well. However, in practise external
restrictions may control what sample rate can be picked on, and so a HF
cut during export isn't a bad idea.
Post by LRN
I tweaked the calculating process by dividing selected sample rate by
two for the purpose of calculating maximum bitrate (that gives us max
129 kbit/s per channel for 44100 - more than enough, if you ask me), and
resulting file will have almost precisely the desired bitrate -
deviations will only occur for lowest bitrates (in case of 44100 Hz and
my sample audio file it was around 48 kbit/s per channel).
Is this the default bit rate suggested by audacity, or the maximum?
Setting the default sounds like a good idea, but I wouldn't want to
restrict the bit rates users can choose if they wish to (e.g. generating
AAC content known to have a lot of critical HF content and to be played
on a high-end system might need a higher bit rate so that the bandwidth
setting can be increased, accepting that big files come out).
Post by LRN
SampleRate/2 cutoff frequency is still used, of course.
Is this a default, controllable or fixed? I wouldn't want to prohibit
users from allowing a lot more signal through. Having quite good
hearing, I'd hate to loose everything above 10 kHz from my audio -
that's worse that my cassette deck can achieve (tops out somewhere about
16 kHz on Chrome tapes).
Post by LRN
Unplayability of mp4 files were caused by my "black magic" patch, i
apologise. I removed it, since it was half-correct anyways (regardless
mp4, mov, 3gp and m4a. For ipod, psp, etc the mp4 extension is used.
Because of that i'm reverting back to simple "mp4" and "rename if you
need mov/3gp/etc". I think "default extension" facility is due, but that
is the story for another day (and i don't see how it could be useful for
non-aac files).
I'm sure we've been here before, but what is the difference?
For .mp4 files we are encoding AAC audio and putting it an MP4
container. Ipods, PSPs play these as-is. Does itunes?

For .mov files we are encoding AAC audio and putting it in a MOV
container. Nice and standard from some pov, but what is it actually
useful for? Obviously quicktime plays it, but does quicktime not also
play .mp4 files?

For .3gp files, AAC audio in some other container again? What might we
use them for - sending to mobile phones?

For .m4a files, are these not the same as .mp4? Are there some
brain-dead applications that actually won't cope with files because they
are named one and not the other?

Ultimately, I would like to achieve a situation where the file extension
doesn't affect what gets exported. By all means have a single export
option with multiple "allowed" extensions (which don't raise warnings).
One of them will have to be the default for when users don't type
anything, and this should be whatever is most likely to work on the host
platform (and can change between platforms). The name of the export
option should be the same on all platforms however.

If there are two many possible settings for AAC to make this reasonable,
then I think we need two export options:
* "AAC for iTunes" with as few controls as possible - probably just
bitrate with some behind-the-scenes magic going on
* "Full AAC" - all controls available, with quite a lot of complexity
available (say controls for bit rate, HF cut-off, container format).

This is the same kind of scheme as for PCM export, where we have a
simple way for most users to work, and an advanced option for unusual
requirements.

Richard
LRN
2008-07-19 17:05:29 UTC
Permalink
Post by Richard Ash
Post by LRN
I installed iTunes again and made a couple of tests. I am positive that
iTunes v7.7.0.43 is unable to play MP4/MOV/etc AAC files, encoded by
ffmpeg (using ffmpeg.exe -i file.wav -acodec libfaac -ar xxx -ab yyy
-cutoff zzz -f fmt file.mp4 or similar commandline; ffmpeg of version
git-c83671b at 11 June 2008), unless it's LC-AAC.
In which case, I think we should add something to the list of options in
the drop-down list - so it reads Low Complexity (Default), Main, LTP or
so.
Even better. A warning message (with "don't show it again" checkbox)
that tells users that anything other than LC-AAC is not supported by at
least half of the software players and by most of the hardware ones.
Post by Richard Ash
Post by LRN
Remember, that this was done using ffmpeg, and it's -ab setting sets up
the bitrate for the whole file (unlike Audacity, which sets up the
bitrate per channel). Obviously, both -ab, -ar and -cutoff have
influence on the outcome: wider bandwidth -> more opportunities to
achieve higher bitrate (and using too wide bandwidth results in
overshot, as codec has to use more bitrate that it was allowed by user).
Bandwidth == Cutoff frequency. Which, in turn, can't be more than one
half of Sample Rate.
How weird. With most other codecs there are two possible modes -
quantiser controlled and bitrate controlled.
Quantizing is something i do not understand about FFmpeg. There's some
"global quality" setting, but i can't grasp the concept yet...
That's why we don't have any quantizer controls for any FFmpeg-enabled
formats, except for Vorbis (because it always works that way).
Post by Richard Ash
In a a quantiser controlled configuration, the amount of information
thrown away is fixed. The bit rate is essentially unpredictable,
determined by the content in the input data. This is basically the
"easy" mode for codec writers, because they just set the parameters and
let the algorithm get on with it.
In a bitrate controlled system the amount of information thrown away is
adjusted to keep the bit rate of the file at a constant level. This
usually means a feedback loop that watches the bit rate of the output
and fiddles with the encoding settings to keep the bit rate under
control. Various tweaks are employed to allow short-term peaks in the
bit rate due to complex data without the long-term bit rate going out of
control.
Uh...right...
Post by Richard Ash
The high frequency roll-off control is unusual to have as a codec
setting, although for almost any codec rolling off the high frequency
content will make the input simpler and easier to encode, allowing a
constant quantiser system to do lower bitrates, and a constant bit rate
system to have fewer artifacts. The cost is the complete loss of the HF
information cut off - but on many budget systems they are inaudible
anyway.
This is AAC feature (the frequency cutoff), or at least AAC is the only
codec that advertises it as one. They even have some kind of prediction
algorithm that allows AAC to reconstruct the other half of the spectre.
Therminology is a mess when it comes to AAC (various AAC-HE, AAC-HEv2
AAC-plus, etc), so i can't tell you anything specific at the moment.
Post by Richard Ash
Post by LRN
I tweaked the calculating process by dividing selected sample rate by
two for the purpose of calculating maximum bitrate (that gives us max
129 kbit/s per channel for 44100 - more than enough, if you ask me), and
resulting file will have almost precisely the desired bitrate -
deviations will only occur for lowest bitrates (in case of 44100 Hz and
my sample audio file it was around 48 kbit/s per channel).
Is this the default bit rate suggested by audacity, or the maximum?
Setting the default sounds like a good idea, but I wouldn't want to
restrict the bit rates users can choose if they wish to (e.g. generating
AAC content known to have a lot of critical HF content and to be played
on a high-end system might need a higher bit rate so that the bandwidth
setting can be increased, accepting that big files come out).
Bit rate is adjustable. The numbers i described are the maximum;
bitrates offered to users are calculated as "maximum/n", where n is
[1..16], so for any sample rate user will have 16 different bitrates
available (including maximum).
Post by Richard Ash
Post by LRN
SampleRate/2 cutoff frequency is still used, of course.
Is this a default, controllable or fixed? I wouldn't want to prohibit
users from allowing a lot more signal through. Having quite good
hearing, I'd hate to loose everything above 10 kHz from my audio -
that's worse that my cassette deck can achieve (tops out somewhere about
16 kHz on Chrome tapes).
Cutoff frequency is fixed - at the moment it is set to the maximum (one
half the sample rate) - FAAC won't accept anything higher (or at least i
think it wouldn't, i may be misinterpreting FAAC source code).

You know what's the worst part? After GSoC ends, FFmpeg will have
built-in LGPL'ed AAC encoder on board, so i'll have to readjust
everything - i bet this new AAC encoder will have different opinion on
the matter of bitrate and cutoff frequencies.
Post by Richard Ash
Post by LRN
Unplayability of mp4 files were caused by my "black magic" patch, i
apologise. I removed it, since it was half-correct anyways (regardless
mp4, mov, 3gp and m4a. For ipod, psp, etc the mp4 extension is used.
Because of that i'm reverting back to simple "mp4" and "rename if you
need mov/3gp/etc". I think "default extension" facility is due, but that
is the story for another day (and i don't see how it could be useful for
non-aac files).
I'm sure we've been here before, but what is the difference?
For .mp4 files we are encoding AAC audio and putting it an MP4
container. Ipods, PSPs play these as-is. Does itunes?
Well, ffmpeg's mov_muxer (the thing responsible for mov/mp4/etc
container multiplexing) thinks there IS a substantial difference between
normal mp4 and ipod mp4.
On the other hand - yes, iTunes handles any variant of mp4 mov_muxer can
produce. I suspect iPod does the same.
Post by Richard Ash
For .mov files we are encoding AAC audio and putting it in a MOV
container. Nice and standard from some pov, but what is it actually
useful for? Obviously quicktime plays it, but does quicktime not also
play .mp4 files?
For .3gp files, AAC audio in some other container again? What might we
use them for - sending to mobile phones?
Yes, 3gp is supposed to be used for mobile devices.
Post by Richard Ash
For .m4a files, are these not the same as .mp4? Are there some
brain-dead applications that actually won't cope with files because they
are named one and not the other?
Some Mac applications are (see the list archive a few mails back).
Post by Richard Ash
Ultimately, I would like to achieve a situation where the file extension
doesn't affect what gets exported. By all means have a single export
option with multiple "allowed" extensions (which don't raise warnings).
One of them will have to be the default for when users don't type
anything, and this should be whatever is most likely to work on the host
platform (and can change between platforms). The name of the export
option should be the same on all platforms however.
I would have preferred to stick with mp4, but Gale thinks it is critical
to have them automatically named as m4a on Mac.
Post by Richard Ash
If there are two many possible settings for AAC to make this reasonable,
* "AAC for iTunes" with as few controls as possible - probably just
bitrate with some behind-the-scenes magic going on
* "Full AAC" - all controls available, with quite a lot of complexity
available (say controls for bit rate, HF cut-off, container format).
Well, if you put it that way, maybe it is better to have "AAC for
iTunes" (dumb version) and "Other FFmpeg-compatible files" for
experienced users? After all, it WILL have presets, so you aren't
required to tinker with the controls - just load the preset and adjust
the bitrate, maybe. And "Other FFmpeg-compatible files" is THE thing i'm
supposed to be working upon at the moment.

By the way, what is the roadmap at the moment? The goals i see are:
1) Finish the expert exporting dialog.
2) Make sure that export produces bugless and compatible output.
3) Revisit all the "TODO"s i left behind.
4) If ondemand loading would be available for non-PCM files by that time
- incorporate ondemand support into FFmpeg importer.
That's all. But you probably have something in mind, like, full import
component redesign...
Richard Ash
2008-07-21 20:33:30 UTC
Permalink
Post by LRN
Post by Richard Ash
In which case, I think we should add something to the list of options in
the drop-down list - so it reads Low Complexity (Default), Main, LTP or
so.
Even better. A warning message (with "don't show it again" checkbox)
that tells users that anything other than LC-AAC is not supported by at
least half of the software players and by most of the hardware ones.
Buy that. One item cleared from the list.
Post by LRN
Uh...right...
Don't worry - more background than terribly important. I'm surprised
that fiddling with the HF control affects the bit rate you get, because
I would expect the codec to be better behaved, but it's not your
problem.
Post by LRN
Post by Richard Ash
The high frequency roll-off control is unusual to have as a codec
setting, although for almost any codec rolling off the high frequency
content will make the input simpler and easier to encode, allowing a
constant quantiser system to do lower bitrates, and a constant bit rate
system to have fewer artifacts. The cost is the complete loss of the HF
information cut off - but on many budget systems they are inaudible
anyway.
This is AAC feature (the frequency cutoff), or at least AAC is the only
codec that advertises it as one. They even have some kind of prediction
algorithm that allows AAC to reconstruct the other half of the spectre.
Therminology is a mess when it comes to AAC (various AAC-HE, AAC-HEv2
AAC-plus, etc), so i can't tell you anything specific at the moment.
OK, sounds nasty. Probably best left alone entirely, especially given
what you say about another encoder in the future.
Post by LRN
Post by Richard Ash
Is this the default bit rate suggested by audacity, or the maximum?
Setting the default sounds like a good idea, but I wouldn't want to
restrict the bit rates users can choose if they wish to (e.g. generating
AAC content known to have a lot of critical HF content and to be played
on a high-end system might need a higher bit rate so that the bandwidth
setting can be increased, accepting that big files come out).
Bit rate is adjustable. The numbers i described are the maximum;
bitrates offered to users are calculated as "maximum/n", where n is
[1..16], so for any sample rate user will have 16 different bitrates
available (including maximum).
As in other email, consider if a more or less continuously-variable
control would be a better idea, as with the Ogg Vorbis control (still
integer in this case, but you get the idea).
Post by LRN
Cutoff frequency is fixed - at the moment it is set to the maximum (one
half the sample rate) - FAAC won't accept anything higher (or at least i
think it wouldn't, i may be misinterpreting FAAC source code).
Wouldn't mean anything useful if it did (my fault for earlier comment, I
was thinking of bandwidth / 2, which would frankly be not unusual for
low bit rate encoding but a bit of a pain for decent stuff). I'm fine
with this being left fully alone for the moment.
Post by LRN
You know what's the worst part? After GSoC ends, FFmpeg will have
built-in LGPL'ed AAC encoder on board, so i'll have to readjust
everything - i bet this new AAC encoder will have different opinion on
the matter of bitrate and cutoff frequencies.
Ah. In that case I suggest that we don't waste a lot more time on this
at the moment - there are probably better uses for it.
Post by LRN
Post by Richard Ash
I'm sure we've been here before, but what is the difference?
For .mp4 files we are encoding AAC audio and putting it an MP4
container. Ipods, PSPs play these as-is. Does itunes?
Well, ffmpeg's mov_muxer (the thing responsible for mov/mp4/etc
container multiplexing) thinks there IS a substantial difference between
normal mp4 and ipod mp4.
On the other hand - yes, iTunes handles any variant of mp4 mov_muxer can
produce. I suspect iPod does the same.
Almost tempted to say, set the ipod version as the only 'MP4' we do -
can't really see what else they would be used for except software
players which are likely to be tolerant (I assume VLC and quicktime will
take Ipod-variant files?).
Post by LRN
Post by Richard Ash
For .mov files we are encoding AAC audio and putting it in a MOV
container. Nice and standard from some pov, but what is it actually
useful for? Obviously quicktime plays it, but does quicktime not also
play .mp4 files?
For .3gp files, AAC audio in some other container again? What might we
use them for - sending to mobile phones?
Yes, 3gp is supposed to be used for mobile devices.
Post by Richard Ash
For .m4a files, are these not the same as .mp4? Are there some
brain-dead applications that actually won't cope with files because they
are named one and not the other?
Some Mac applications are (see the list archive a few mails back).
OK, hold the question backwards. What (apart from pedants) wouldn't be
happy if we had an option which said "M4A", and produced a file using
the Ipod muxer with a .m4a extension? These would presumably go into
iTunes on all platforms, and onto Ipods? As a contraction of mp4a (a
decent abbreviation) it's about as good as any, given what Gale has said
about the iTunes store.
Post by LRN
Well, if you put it that way, maybe it is better to have "AAC for
iTunes" (dumb version) and "Other FFmpeg-compatible files" for
experienced users? After all, it WILL have presets, so you aren't
required to tinker with the controls - just load the preset and adjust
the bitrate, maybe.
Fair point. In which case I think simplifying the separate AAC exporter
(whatever we call it, and I'm liking M4A) is a good idea, probably take
the profile out (leave fixed as LC) and just offer a bit rate control -
this would just about be within the comprehension of users.

Re roadmap, see separate email.

Richard
Richard Ash
2008-07-21 20:52:45 UTC
Permalink
Post by LRN
1) Finish the expert exporting dialog.
2) Make sure that export produces bugless and compatible output.
3) Revisit all the "TODO"s i left behind.
4) If ondemand loading would be available for non-PCM files by that time
- incorporate ondemand support into FFmpeg importer.
That's all. But you probably have something in mind, like, full import
component redesign...
I think input will have to wait (but I don't rule out doing it quite
soon independently). What I would like to add as another point is to
look at Metadata import and export.

I can see that you have some code in place, because if I import a tagged
Ogg file through ffmpeg, I get rows of little square boxes in the track
title, album title, artist name and genre entries. The track number
survives but the date seems not to (nothing of note in the log window in
a debug build). I don't seem to have anything that actually reads
metadata for most of the formats, so I'll pass on what works there (I've
just tried an ogg file I know has tags, and failed to read them in VLC).

I would rate 4) as very much nice-to-have, but I think there are bigger
issues for both you and Micheal to deal with (I suspect the rogue
audacity process may be due to a thread of his).

So I think the things we will ultimately rate highest will be compatible
exports and some basic metadata support that works for the main fields.
These are the boring bits that users will notice the absence of.

Beyond this the expert export dialogue will get attention, if not
necessarily use, and things like stream positioning are definitely in
the "nice to have" category. If they are easy, you may want to knock
some of them off, but they are not deal-breakers for most users.

Richard
LRN
2008-08-03 20:44:02 UTC
Permalink
Post by Richard Ash
Post by LRN
1) Finish the expert exporting dialog.
2) Make sure that export produces bugless and compatible output.
3) Revisit all the "TODO"s i left behind.
4) If ondemand loading would be available for non-PCM files by that time
- incorporate ondemand support into FFmpeg importer.
That's all. But you probably have something in mind, like, full import
component redesign...
I think input will have to wait (but I don't rule out doing it quite
soon independently). What I would like to add as another point is to
look at Metadata import and export.
Current FFmpeg metadata support (this list may not be 100% correct, but
as far as i know it is):
aiff - read/write
ape - read
asf - read/write
avi - read/write
matroska - read/write
mov - read/write
mp3 - read/write
nsv - read
nut - read/write
ogg - read/write
rm - read/write
rpl - read
wc3movie - read
For all other format metadata support is not implemented explicitly. I
did not checked, maybe it can inject id3v2 tags into arbitrary
files...probably not.

At the moment i believe i fixed metadata import/export enough for it to
be tested.
Post by Richard Ash
So I think the things we will ultimately rate highest will be compatible
exports and some basic metadata support that works for the main fields.
These are the boring bits that users will notice the absence of.
Done. Requires testing.
Post by Richard Ash
Beyond this the expert export dialogue will get attention, if not
necessarily use
Dialog should be working. Possible enchantments are:
Reworked preset load/save/remove code (to use external xml file rather
than gPrefs).
Customizable format-codec compatibility list (list would be loaded from
file rather than being hardcoded).
Post by Richard Ash
, and things like stream positioning are definitely in
the "nice to have" category.
What's about stream positioning?
Richard Ash
2008-08-11 20:57:45 UTC
Permalink
Post by LRN
Current FFmpeg metadata support (this list may not be 100% correct, but
aiff - read/write
ape - read
asf - read/write
avi - read/write
matroska - read/write
mov - read/write
mp3 - read/write
nsv - read
nut - read/write
ogg - read/write
rm - read/write
rpl - read
wc3movie - read
For all other format metadata support is not implemented explicitly. I
did not checked, maybe it can inject id3v2 tags into arbitrary
files...probably not.
ID3 injection is not a good idea - very few things are likely to read
them, and some will play them (which sounds nasty!).

That's annoying - it seems to mean that we don't have support for tags
in AAC files (unless mov support means mov container, in which case we
should?). Anyhow, I can't currently persuade it to work with .m4a files.

With WMA (2), I can get the "Artist name" back on import, but not any of
the other tags. Is there something asymmetric about the naming being
used somewhere? Unfortunately I can't get VLC to show me the tags in the
exported file at the moment.

AC3 seems to be completely broken at the moment as well - none of the
tags come back in from the files exported from audacity.

Richard
LRN
2008-08-12 03:23:31 UTC
Permalink
Post by Richard Ash
Post by LRN
Current FFmpeg metadata support (this list may not be 100% correct, but
aiff - read/write
ape - read
asf - read/write
avi - read/write
matroska - read/write
mov - read/write
mp3 - read/write
nsv - read
nut - read/write
ogg - read/write
rm - read/write
rpl - read
wc3movie - read
For all other format metadata support is not implemented explicitly. I
did not checked, maybe it can inject id3v2 tags into arbitrary
files...probably not.
By the way, i made this list by looking for a code accessing the
->author or ->title fields, which points out that the corresponding
importer/exporter should support metadata. But in reality this support
may be broken (see MOV/MP4 below).
Post by Richard Ash
ID3 injection is not a good idea - very few things are likely to read
them, and some will play them (which sounds nasty!).
I agree.
Post by Richard Ash
That's annoying - it seems to mean that we don't have support for tags
in AAC files (unless mov support means mov container, in which case we
should?). Anyhow, I can't currently persuade it to work with .m4a files.
AAC files are raw files, they aren't supposed to have any metadata (i
think...).
For MOV and MP4-like containers only metadata export works. Import
should be working too, but it isn't (libavformat code is broken, FFmpeg
developers said that "patches are welcome").
Post by Richard Ash
With WMA (2), I can get the "Artist name" back on import, but not any of
the other tags. Is there something asymmetric about the naming being
used somewhere? Unfortunately I can't get VLC to show me the tags in the
exported file at the moment.
WMA should support exporting and importing for Title, Author, Copyright
(Audacity doesn't have it) and Comment fields.
Post by Richard Ash
AC3 seems to be completely broken at the moment as well - none of the
tags come back in from the files exported from audacity.
Same as with AAC files.

Also, i just found a bug - track title was not being written into file.
Fixing that.
Richard Ash
2008-08-13 21:12:22 UTC
Permalink
Post by LRN
Post by Richard Ash
That's annoying - it seems to mean that we don't have support for tags
in AAC files (unless mov support means mov container, in which case we
should?). Anyhow, I can't currently persuade it to work with .m4a files.
AAC files are raw files, they aren't supposed to have any metadata (i
think...).
For MOV and MP4-like containers only metadata export works. Import
should be working too, but it isn't (libavformat code is broken, FFmpeg
developers said that "patches are welcome").
So if I leave the "M4A (AAC)" exporter on default (no extension) this
should work? It looks like it does - Amarok gets Title, Artist and Year
out correctly, as well as a Composer field duplicating the Artist one
even though I didn't set it.
Import is indeed broken, but as you say that's an FFmpeg problem.
Post by LRN
Post by Richard Ash
With WMA (2), I can get the "Artist name" back on import, but not any of
the other tags. Is there something asymmetric about the naming being
used somewhere? Unfortunately I can't get VLC to show me the tags in the
exported file at the moment.
WMA should support exporting and importing for Title, Author, Copyright
(Audacity doesn't have it) and Comment fields.
Ack, Artist and Title fields export correctly from Audacity to Amarok,
and import back OK to Audacity. Looks like that one is fine.
Post by LRN
Post by Richard Ash
AC3 seems to be completely broken at the moment as well - none of the
tags come back in from the files exported from audacity.
Same as with AAC files.
Also, i just found a bug - track title was not being written into file.
Fixing that.
One good report, import of metadata from .ra files is working - I
imported something I had stream-dumped, and up came the data. So that
works for Artist Name and Track Title at least (probably all it has in
it).

The big thing this work now lacks is documentation. This isn't something
that can come within GSoC because of the strange way it's funded / paid
for, but is rather helpful for getting people to use the features, and
not just moan that it doesn't work for them.

The key thing I think would be a "what does what" page for the Custom
FFmpeg Export dialogue - I will admit to being more or less lost as to
what has to be filled in, what I should ignore and what will be
auto-detected. Even a description of how the options map to the
command-line ffmpeg options would be helpful.

If you could arrange for errors in exports from this dialogue to appear
in a window (so users don't have to go and hunt in the log for them) it
might be nice, but by no means essential to have it for the freeze (I
would like it in a putative first beta after GSoC completes, because
most users won't realise that the explanation as to why they got a zero
byte exported file is some line about not being able to find audio
codecs in the log window).

Because ffmpeg is such a complex animal, it may be worth compiling a
short list of the ffmpeg-based features that we know work and are
testing, with a notice that other things may work, but we aren't
actively testing them. Something like
<container> <codec> <audio import?> <audio export?> <metadata import?>
<metadata export?>

Richard
Gale Andrews
2008-08-14 04:27:11 UTC
Permalink
|
LRN
2008-08-14 17:29:07 UTC
Permalink
Re: the AAC export quality controls, I made a table of export results
Loading Image...
* What does "automatic" mean exactly and how would you explain it to the
user? It seems on paper to produce higher bit rate than the highest
quality (q500)?
* The sample rate exported seems predictable, albeit with the FFmpeg (?)
bug noted before where low sample rates are doubled up to a maximum
of 44.1 KHz (e.g. 8 KHz exported as 16 KHz).
* If I choose non-automatic quality, then for a given project rate I
get the same bit rate and file size in the exported file whether
q is 250 or 500? Seems at variance with Richard's finding?
Also I tried a 44100 Hz export at q50 and q350 - same bit rate
and same file size in the exported files.
* Richard said if he selected a low quality at a high sample rate it
asked for a valid sample rate. Does it work like that? For me it
accepts every quality I try at 44100 Hz, and refuses every one at
96000 Hz, presumably according to the list of supported rates
that it offers.
* Rather than all this, what are the problems having some sort of target
bit rate (on a slider if you want), and people just understand if they
choose a lower sample rate they get lower quality, as for other
formats?
Alternatively, I quite liked your idea of q1, q0.8. q0.5 ... where q1
is "defined" as e.g. "no perceptible loss for casual listening with
average difficulty material", or as "128 Kbps MP3/96 kbps AAC".
Can we get to such a statement though? I don't think so unless they
choose 44 KHz or above. Even if we can, is quality a standard
control for exporting AAC in other apps, as it is for OGG? I think
users of other apps. will be familiar with AAC bit rate and will be
asking us what bit rate they are going to get if they choose a given
quality.
http://www.gaclrecords.org.uk/0068.png
The files marked X in Foobar had completely unacceptable warbling
distortion, much like extreme noise removal. I did not check every
file in iTunes but a few were the same. M4A files produced by iTunes
play fine in ITunes and Foobar. I verified this again after rebooting,
before sending this, and it's the same on my other PC which has
a different sound device. Do any other Windows users find this?
Sorry again. Quality computation was really messed up (quality was
always zero no matter what). I just fixed it.
Now lowest available quality is 10 (highest is still 500). There is no
automatic quality (and never really was).
Also, now cutoff bandwidth is set to zero rather than half of a sample
rate (which is how ffmpeg works).
Essentially, exporing audio file to AAC with quality = 100 from Audacity
is now equivalent to
ffmpeg -i <source> -aq 100 <target>
Before it was something like
ffmpeg -i <source> -aq 100 -cutoff 22050 <target>
I believe that now encoder's behaviour should be optimal, i.e. it works
the same way as ffmpeg does.
If you have time, please, re-test problematic AAC export cases (sample
rate anomalities, distortions).
* Exported GSM-WAV and GSM-AIFF files cannot be played on most supported
players, or may not play for the full length
I'll look into it.
* "Other uncompressed files" is producing AIFF, not WAV unless you add
WAV extension. It should produce WAV in Windows and AIFF on Mac
I think (or at worst, WAV for all platforms).
I thought i fixed that...ok, let's see...
Re: the .mpg import problem if the audio content is PCM, if everyone
had FFmpeg I guess then the answer would be to remove "mpg"
static const wxChar *exts[] =
{
wxT("mp3"),
wxT("mp2"),
wxT("mpg"),
wxT("mpeg"),
wxT("mpa")
};
and let FFmpeg handle those videos. So a) should we put the pre-GSoC
bug "ImportMP3 can't tell whether a particular file is mp3 or not" in
the Release Checklist"? b) is there some way "mpg" and "mpeg" can be
taken by the FFmpeg importer if FFmpeg is detected in Preferences?
I'll try to do that, but that would be very nasty hack.
Gale Andrews
2008-08-15 03:17:52 UTC
Permalink
|
LRN
2008-08-15 05:05:33 UTC
Permalink
|
LRN
2008-08-15 16:46:48 UTC
Permalink
Post by LRN
* Exported GSM-WAV and GSM-AIFF files cannot be played on most supported
players, or may not play for the full length
I tried
ffmpeg -i<source> -ac 1 -ar 8000 -ab 13000 -acodec libgsm_ms
<target.wav>
ffmpeg -i<source> -ac 1 -ar 8000 -ab 13000 -acodec libgsm
<target.aiff>
Same here - unplayable (FFDShow + MPC).
However,
ffmpeg -i<source> -ac 1 -ar 8000 -ab 13000 -acodec libgsm_ms
<target.avi>
ffmpeg -i<source> -ac 1 -ar 8000 -ab 13000 -acodec libgsm<target.mov>
plays in MPC.
..The best format for GSM should be raw GSM, but ffmpeg can't
write it (or it can,
but i can't figure out how to do that).
...As for GSM-WAV, it seems that ffmpeg's way to write GSM into WAV
differs
from Microsoft's. Maybe i should remove it completely? After all,
libsndfile can encode gsm...
My 2p is remove if from FFmpeg, but it's too buried in the "Other
uncompressed
files" (and if someone chooses WAVEX header there, they will get an
error).
Why not have "GSM-WAV (mobiles)" and "GSM-AIFF (mobiles)" underneath
WAV..16 bit PCM and AIFF..16 bit PCM as explicit options, using WAV
(Microsoft) header? We should still fix the WAVEX problems (e.g. the
user
today where WAVEX ULaw is unplayable), but I think that solution is
better than what we have now.
Probably.
Removed FFmpeg's GSM export, added libsndfile's GSM export.
I think "Specify Uncompressed Options" has some undesirable locking
somewhere? Choose "WAV (Microsoft)" header then "GSM 6.10" encoding
from the 12 choices, hit OK. then hit Options again. Click on encoding
and you now only have three options for WAV (Microsoft). You have to
click and select WAV (Microsoft) again before you can choose all the
encodings for that header. If you choose PVF header and 32 bit (out of
8, 16 and 32 bit choices), OK, and hit Options again, you now only see a
single 32 bit PCM encoding option.
Yeah, i noticed that too. I'll look into it.
Fixed.
Gale Andrews
2008-08-16 00:09:04 UTC
Permalink
|

LRN
2008-08-14 18:01:12 UTC
Permalink
* Exported GSM-WAV and GSM-AIFF files cannot be played on most supported
players, or may not play for the full length
I tried
ffmpeg -i <source> -ac 1 -ar 8000 -ab 13000 -acodec libgsm_ms <target.wav>
ffmpeg -i <source> -ac 1 -ar 8000 -ab 13000 -acodec libgsm <target.aiff>
Same here - unplayable (FFDShow + MPC).
However,
ffmpeg -i <source> -ac 1 -ar 8000 -ab 13000 -acodec libgsm_ms <target.avi>
ffmpeg -i <source> -ac 1 -ar 8000 -ab 13000 -acodec libgsm <target.mov>
plays in MPC.
Same goes for matroska and nut formats. But none of these is common for
audio (even mov is usually meant to be video/audio format). The best
format for GSM should be raw GSM, but ffmpeg can't write it (or it can,
but i can't figure out how to do that).
As for GSM-WAV, it seems that ffmpeg's way to write GSM into WAV differs
from Microsoft's. Maybe i should remove it completely? After all,
libsndfile can encode gsm...
LRN
2008-08-14 18:16:26 UTC
Permalink
Also exporting GSM 6.10 in a WAVEX container via
"Other uncompressed files" throws a "cannot export error", but used
to work in 1.3.5 (yes it is a mono file).
libsndfile, wav.c, line 1041.
Looks like wavex_write_header doesn't knows how to store
SF_FORMAT_GSM610 in WAVEX container.
Gale Andrews
2008-08-14 18:15:52 UTC
Permalink
|
LRN
2008-08-14 18:44:43 UTC
Permalink
|
LRN
2008-08-14 18:33:21 UTC
Permalink
* "Other uncompressed files" is producing AIFF, not WAV unless you add
WAV extension. It should produce WAV in Windows and AIFF on Mac
I think (or at worst, WAV for all platforms).
Fixed.
LRN
2008-08-14 05:11:00 UTC
Permalink
Post by Richard Ash
The key thing I think would be a "what does what" page for the Custom
FFmpeg Export dialogue - I will admit to being more or less lost as to
what has to be filled in, what I should ignore and what will be
auto-detected. Even a description of how the options map to the
command-line ffmpeg options would be helpful.
I made tooltips for most of the controls. Aren't they helpful?
Post by Richard Ash
If you could arrange for errors in exports from this dialogue to appear
in a window (so users don't have to go and hunt in the log for them) it
might be nice, but by no means essential to have it for the freeze (I
would like it in a putative first beta after GSoC completes, because
most users won't realise that the explanation as to why they got a zero
byte exported file is some line about not being able to find audio
codecs in the log window).
Yeah, i had such idea. Maybe i can make a subclass of progress dialog
with multiline text control attached. It would catch libav* errors and
display them...
No, that won't do. Progress dialog disappears after exporting is
complete (successful or not)...
Post by Richard Ash
Because ffmpeg is such a complex animal, it may be worth compiling a
short list of the ffmpeg-based features that we know work and are
testing, with a notice that other things may work, but we aren't
actively testing them. Something like
<container> <codec> <audio import?> <audio export?> <metadata import?>
<metadata export?>
You just mixed three different lists together. It should be like this:
<container> <metadata import?> <metadata export?> <demux?> <mux?>
...
<codec> <audio import?> <audio export?>
...
<container> <read <codec>?> <write <codec>?>

I can make 1st list and 2nd list. 3rd list is, essentially, a
compatibility list, and i guess it's not something you had in mind (it's
long, as you can see from the code). Though i can make it too, maybe as
a table.
Gale Andrews
2008-07-20 21:17:56 UTC
Permalink
Again, sorry for length but replying to several long posts by Richard
and LRN in one.

|
Gale Andrews
2008-07-21 16:21:54 UTC
Permalink
Hi LRN

I just noticed the "Select file(s) for batch processing..." dialogue
(accessed by File > Apply Chain) lacks "All supported files" and
"FFmpeg-compatible files" filters.


Thanks


Gale
Richard Ash
2008-07-19 16:36:17 UTC
Permalink
* Both Richard and I would prefer sample rates were taken out of
of format options for sake of consistency. Do you see any drawbacks
to this?
Well, now for AAC encoding bitrate range depends on sample rate. Either
i have to make the dialog aware of the AudacityProject contents, or
leave as it is.
I would put the full range of possible bitrates in the AAC dialogue all
the time, and handle the incompatible sample rate / bit rate
combinations subsequently.
For other formats removing sample rate is easier.
What should be Audacity's policy when track's sample rate doesn't
matches any of the sample rates supported by format? Error message?
Upsampling? Downsampling? Up/Downsampling (to closest rate)? Forced
resampling (for formats such as GSM which supports only one sample rate).
Richard/Leland would be more expert than me here, but as I (think I)
said before, what we do with MP3 is offer a dialogue when the sample
rate is unsupported for the chosen bit rate. If the rate is unsupported,
it offers the nearest rate below, from what I now see. Would that work
for the AAC problem?
What I think the MP3 exporter does is pop up a dialogue box when you try
and export with an invalid (or in LAME's case, discouraged) sample rate.

This currently reads:

"The project sample rate (X) and bit rate (Y) combination is not
supported by the MP3 format. You may re-sample to one of the rates
below"

then has a list box of sample rates that the bit rate can be used on. If
you hit Cancel the export is stopped (so you can change your bit rate
choice), if you hit OK, then the export goes ahead with the chosen
sample rate.

At the moment this dialogue is hidden in the MP3 exporter code, but
could be made into a stand-alone class with more flexible wording (this
might actually simplify things if the code decamped to the exporter
class).
The other alternative is to always choose export rate in the format options,
including native Audacity formats. This is another way to be consistent
(and avoid a second dialogue or error message). I suppose it would still
have to be decided if the offered sample rate in the export options was
totally independent of the project rate or offered a close match. I think
it should be independent.
I don't particularly like this, because it means more things to mess
about with, and to end up with an export that doesn't sound like the
project did before export.

Richard
LRN
2008-07-20 10:31:06 UTC
Permalink
Post by Richard Ash
* Both Richard and I would prefer sample rates were taken out of
of format options for sake of consistency. Do you see any drawbacks
to this?
Well, now for AAC encoding bitrate range depends on sample rate. Either
i have to make the dialog aware of the AudacityProject contents, or
leave as it is.
I would put the full range of possible bitrates in the AAC dialogue all
the time, and handle the incompatible sample rate / bit rate
combinations subsequently.
Please explain "subsequent handling" to me.
Post by Richard Ash
For other formats removing sample rate is easier.
What should be Audacity's policy when track's sample rate doesn't
matches any of the sample rates supported by format? Error message?
Upsampling? Downsampling? Up/Downsampling (to closest rate)? Forced
resampling (for formats such as GSM which supports only one sample rate).
Richard/Leland would be more expert than me here, but as I (think I)
said before, what we do with MP3 is offer a dialogue when the sample
rate is unsupported for the chosen bit rate. If the rate is unsupported,
it offers the nearest rate below, from what I now see. Would that work
for the AAC problem?
What I think the MP3 exporter does is pop up a dialogue box when you try
and export with an invalid (or in LAME's case, discouraged) sample rate.
"The project sample rate (X) and bit rate (Y) combination is not
supported by the MP3 format. You may re-sample to one of the rates
below"
then has a list box of sample rates that the bit rate can be used on. If
you hit Cancel the export is stopped (so you can change your bit rate
choice), if you hit OK, then the export goes ahead with the chosen
sample rate.
At the moment this dialogue is hidden in the MP3 exporter code, but
could be made into a stand-alone class with more flexible wording (this
might actually simplify things if the code decamped to the exporter
class).
And there is no way to know in advance which combination of sample
rate/bit rate is supported and which is not? That's awkward...This way
one has to re-initiate the export procedure again and again until the
right combination of options is set.
There must be a better way.
Richard Ash
2008-07-21 20:15:36 UTC
Permalink
Post by LRN
Post by Richard Ash
I would put the full range of possible bitrates in the AAC dialogue all
the time, and handle the incompatible sample rate / bit rate
combinations subsequently.
Please explain "subsequent handling" to me.
Dealt with in the same way as for MP3, whoose description was further
down the same email, i.e. a dialogue that says sorry, you can't do that,
this is what you can do.
Post by LRN
Post by Richard Ash
What the MP3 exporter does is pop up a dialogue box when you try
and export with an invalid (or in LAME's case, discouraged) sample rate.
"The project sample rate (X) and bit rate (Y) combination is not
supported by the MP3 format. You may re-sample to one of the rates
below"
then has a list box of sample rates that the bit rate can be used on. If
you hit Cancel the export is stopped (so you can change your bit rate
choice), if you hit OK, then the export goes ahead with the chosen
sample rate.
At the moment this dialogue is hidden in the MP3 exporter code, but
could be made into a stand-alone class with more flexible wording (this
might actually simplify things if the code decamped to the exporter
class).
And there is no way to know in advance which combination of sample
rate/bit rate is supported and which is not? That's awkward...This way
one has to re-initiate the export procedure again and again until the
right combination of options is set.
The list in the dialogue offers you the possible sample rates for that
bit rate, so you know what your options are from that point of view. The
only thing you don't know is how high you would have to raise the bit
rate in order to get a specific sample rate.

I suspect most users couldn't care less about the sample rate, so for
them the dialogue is a compromise between full automation (which we used
to do, but confused people when LAME did it's own thing and downsampled
low bit rate files, especially if they then used dumb flash-based
players which didn't read the sample rate headers) and a manual system
(where they have to adjust multiple parameters before exporting, and
don't know what to do). Generally it hasn't generated many complaints
from users so far.

If the bit rates for AAC are essentially arbitrary (which I sense they
may be) then might a slider or a spin box be better interface to them?
You could then slip a line of text underneath that noted the minimum bit
rate at this sample rate, but allow the list / slider lower, leading to
the dialogue as with MP3 (this then looks more like the Ogg Vorbis
exporter).

Richard
Gale Andrews
2008-07-23 01:51:24 UTC
Permalink
|
LRN
2008-07-23 10:08:11 UTC
Permalink
|
LRN
2008-08-04 14:41:48 UTC
Permalink
Post by Richard Ash
Post by LRN
Post by Richard Ash
I would put the full range of possible bitrates in the AAC dialogue all
the time, and handle the incompatible sample rate / bit rate
combinations subsequently.
Please explain "subsequent handling" to me.
Dealt with in the same way as for MP3, whoose description was further
down the same email, i.e. a dialogue that says sorry, you can't do that,
this is what you can do.
Post by LRN
Post by Richard Ash
What the MP3 exporter does is pop up a dialogue box when you try
and export with an invalid (or in LAME's case, discouraged) sample rate.
"The project sample rate (X) and bit rate (Y) combination is not
supported by the MP3 format. You may re-sample to one of the rates
below"
then has a list box of sample rates that the bit rate can be used on. If
you hit Cancel the export is stopped (so you can change your bit rate
choice), if you hit OK, then the export goes ahead with the chosen
sample rate.
At the moment this dialogue is hidden in the MP3 exporter code, but
could be made into a stand-alone class with more flexible wording (this
might actually simplify things if the code decamped to the exporter
class).
And there is no way to know in advance which combination of sample
rate/bit rate is supported and which is not? That's awkward...This way
one has to re-initiate the export procedure again and again until the
right combination of options is set.
The list in the dialogue offers you the possible sample rates for that
bit rate, so you know what your options are from that point of view. The
only thing you don't know is how high you would have to raise the bit
rate in order to get a specific sample rate.
I suspect most users couldn't care less about the sample rate, so for
them the dialogue is a compromise between full automation (which we used
to do, but confused people when LAME did it's own thing and downsampled
low bit rate files, especially if they then used dumb flash-based
players which didn't read the sample rate headers) and a manual system
(where they have to adjust multiple parameters before exporting, and
don't know what to do). Generally it hasn't generated many complaints
from users so far.
Done. Now AAC and AC3 will check for sample rate compatibility.

Also: good news from FFmpeg developers camp. I spoke with kshishkov, and
he said that both his LGPL'ed AAC encoder and superdump's LGPL'ed AAC
decoder will be ready by the end of this month. I will try to apply
necessary patches to my libav* builds and adjust Audacity
accordingly..uh, maybe at August 26th .
Richard Ash
2008-08-04 20:43:49 UTC
Permalink
Post by LRN
Done. Now AAC and AC3 will check for sample rate compatibility.
Testing this is causing a few problems:

* Compile errors:

export/ExportFFmpeg.cpp:1201: error: no matching function for call to
‘ExportFFmpegOptions::OnFormatList(wxCommandEvent)’
export/ExportFFmpeg.cpp:1068: note: candidates are: void
ExportFFmpegOptions::OnFormatList(wxCommandEvent&)
export/ExportFFmpeg.cpp:1204: error: no matching function for call to
‘ExportFFmpegOptions::OnCodecList(wxCommandEvent)’
export/ExportFFmpeg.cpp:1069: note: candidates are: void
ExportFFmpegOptions::OnCodecList(wxCommandEvent&)


I side-stepped these locally by creating functions void
DoCodecList(void) and void DoFormatList(void) which do what OnCodecList
and OnFormatList used to do, then made the latter functions call the Do*
functions (as they ignored their arguments anyway). This doesn't seem a
good solution, but I couldn't get the compiler to accept a default
argument of null (because they are call-by-reference functions).

Anyway, I then got it to compile (with a lot of warnings), but when I
tried to run it some problems showed up:

* AAC export dialogue has layout issues:
Loading Image...

When I click OK, accepting whatever I'm getting, I then get an assertion
failure:
/home/ra/Documents/programming/audacity/wx-2.8.7.1/include/wx/arrstr.h(155): assert "nIndex < m_nCount" failed in Item(): wxArrayString: index out of bounds. (full back-trace from the dialogue at the end of this email. Can do a trace in GDB if needed). This was trying to export 30 seconds of 440Hz tone with a sample rate of 8 kHz.
Post by LRN
Also: good news from FFmpeg developers camp. I spoke with kshishkov, and
he said that both his LGPL'ed AAC encoder and superdump's LGPL'ed AAC
decoder will be ready by the end of this month. I will try to apply
necessary patches to my libav* builds and adjust Audacity
accordingly..uh, maybe at August 26th .
This is of course outside of the Summer of Code period as far as
Audacity is concerned. Don't let that stop you, but we can't count it as
part of the project work for GSoC.

I see (from the commit log) you have at least attempted to add support
for streams in imported files that don't start at the beginning of the
file - that's what I meant by Stream Positioning.

I've got (or had) some Ogg vorbis files which contain many chained
streams (they are dumps from internet radio which starts a new stream
automagically each time a new song is played), which make quite good
test cases because the imported tracks should play back the same as the
original audio if we are getting it right. Not sure where they are
though, so haven't tried this.

Richard

ASSERT INFO:
/home/ra/Documents/programming/audacity/wx-2.8.7.1/include/wx/arrstr.h(155): assert "nIndex < m_nCount" failed in Item(): wxArrayString: index out of bounds

BACKTRACE:
[1] wxArrayString::Item(unsigned int)
cons) /home/ra/Documents/programming/audacity/wx-2.8.7.1/include/wx/arrstr.h:157
[2] wxArrayString::operator[](unsigned int)
cons) /home/ra/Documents/programming/audacity/wx-2.8.7.1/include/wx/arrstr.h:161
[3] ExportFFmpeg::AskResample(int, int, int, int, int
const*) /home/ra/Documents/programming/audacity/13branch/wx2.8/src/export/ExportFFmpeg.cpp:2723
[4]
ExportFFmpeg::InitCodecs(AudacityProject*) /home/ra/Documents/programming/audacity/13branch/wx2.8/src/export/ExportFFmpeg.cpp:2307
[5] ExportFFmpeg::Init(char const*,
AudacityProject*) /home/ra/Documents/programming/audacity/13branch/wx2.8/src/export/ExportFFmpeg.cpp:2261
[6] ExportFFmpeg::Export(AudacityProject*, int, wxString, bool, double,
double, MixerSpec*, Tags*,
int) /home/ra/Documents/programming/audacity/13branch/wx2.8/src/export/ExportFFmpeg.cpp:2594
[7]
Exporter::ExportTracks() /home/ra/Documents/programming/audacity/13branch/wx2.8/src/export/Export.cpp:743
[8] Exporter::Process(AudacityProject*, bool, double,
double) /home/ra/Documents/programming/audacity/13branch/wx2.8/src/export/Export.cpp:355
[9]
AudacityProject::OnExport() /home/ra/Documents/programming/audacity/13branch/wx2.8/src/Menus.cpp:2482
[10]
AudacityProjectCommandFunctor::operator()(int) /home/ra/Documents/programming/audacity/13branch/wx2.8/src/Menus.cpp:154
[11] CommandManager::HandleCommandEntry(CommandListEntry*, unsigned int,
unsigned
int) /home/ra/Documents/programming/audacity/13branch/wx2.8/src/commands/CommandManager.cpp:937
[12] CommandManager::HandleMenuID(int, unsigned int, unsigned
int) /home/ra/Documents/programming/audacity/13branch/wx2.8/src/commands/CommandManager.cpp:948
[13]
AudacityProject::OnMenu(wxCommandEvent&) /home/ra/Documents/programming/audacity/13branch/wx2.8/src/Project.cpp:1438
LRN
2008-08-04 22:00:48 UTC
Permalink
Post by Richard Ash
Post by LRN
Done. Now AAC and AC3 will check for sample rate compatibility.
export/ExportFFmpeg.cpp:1201: error: no matching function for call to
‘ExportFFmpegOptions::OnFormatList(wxCommandEvent)’
export/ExportFFmpeg.cpp:1068: note: candidates are: void
ExportFFmpegOptions::OnFormatList(wxCommandEvent&)
export/ExportFFmpeg.cpp:1204: error: no matching function for call to
‘ExportFFmpegOptions::OnCodecList(wxCommandEvent)’
export/ExportFFmpeg.cpp:1069: note: candidates are: void
ExportFFmpegOptions::OnCodecList(wxCommandEvent&)
I side-stepped these locally by creating functions void
DoCodecList(void) and void DoFormatList(void) which do what OnCodecList
and OnFormatList used to do, then made the latter functions call the Do*
functions (as they ignored their arguments anyway). This doesn't seem a
good solution, but I couldn't get the compiler to accept a default
argument of null (because they are call-by-reference functions).
No, this solution is good enough. Fixed.
Post by Richard Ash
Anyway, I then got it to compile (with a lot of warnings), but when I
http://www.audacityteam.org/wiki/index.php?title=Image:AAC-export-issue.png
On Windows this dialog looks a bit better (though still too small), but
i don't know how to fix that. How to tell ShuttleGui that i want this
slider to be of some particular size?
I changed layout a bit, but it's still ugly.
Post by Richard Ash
When I click OK, accepting whatever I'm getting, I then get an assertion
/home/ra/Documents/programming/audacity/wx-2.8.7.1/include/wx/arrstr.h(155): assert "nIndex< m_nCount" failed in Item(): wxArrayString: index out of bounds. (full back-trace from the dialogue at the end of this email. Can do a trace in GDB if needed). This was trying to export 30 seconds of 440Hz tone with a sample rate of 8 kHz.
Fixed.
Post by Richard Ash
Post by LRN
Also: good news from FFmpeg developers camp. I spoke with kshishkov, and
he said that both his LGPL'ed AAC encoder and superdump's LGPL'ed AAC
decoder will be ready by the end of this month. I will try to apply
necessary patches to my libav* builds and adjust Audacity
accordingly..uh, maybe at August 26th .
This is of course outside of the Summer of Code period as far as
Audacity is concerned. Don't let that stop you, but we can't count it as
part of the project work for GSoC.
Why? I have to submit code to Google only after September 3, August 31
being evaluation deadline.
Post by Richard Ash
I see (from the commit log) you have at least attempted to add support
for streams in imported files that don't start at the beginning of the
file - that's what I meant by Stream Positioning.
I've got (or had) some Ogg vorbis files which contain many chained
streams (they are dumps from internet radio which starts a new stream
automagically each time a new song is played), which make quite good
test cases because the imported tracks should play back the same as the
original audio if we are getting it right. Not sure where they are
though, so haven't tried this.
I have one (radio station, not ogg file!). I'll try to make multistream
Ogg and see how it is imported now.
Richard Ash
2008-08-05 20:26:24 UTC
Permalink
Post by LRN
Fixed
Compile errors are indeed gone.

I've noticed one warning that is a result of code changes elsewhere you
might want to deal with: project.GetRate() now returns a double, not an
integer.
export/ExportFFmpeg.cpp:2281: warning: converting to ‘int’ from ‘double’
which suggests that the sample rate member of the class should be
double, except that that has knock on effects.

In practical terms fractional rates won't work in ffmpeg, so you have to
round to nearest integer somewhere, you just need a decision (and a
cast) as to where.

Back where we were, which was AAC export. It's looking a lot better now
- I can't break it badly. The quality I select has an effect on the file
I get, and if I try to choose a low quality at a high sample rate, it
asks for a valid sample rate. The dialogue is now usable. I agree it
could be nicer, but I have no idea how to achieve that - anyone else any
ideas?

I think I agree with Gale that a smaller scale on the slider might be
more intelligible. Is there any particular reason for -1 to 500 as the
scale?

AC3 also seems to be working, or at least I can't crash it, and I get
out files that will import back into Audacity.
Post by LRN
Post by Richard Ash
Post by LRN
Also: good news from FFmpeg developers camp. I spoke with kshishkov, and
he said that both his LGPL'ed AAC encoder and superdump's LGPL'ed AAC
decoder will be ready by the end of this month. I will try to apply
necessary patches to my libav* builds and adjust Audacity
accordingly..uh, maybe at August 26th .
This is of course outside of the Summer of Code period as far as
Audacity is concerned. Don't let that stop you, but we can't count it as
part of the project work for GSoC.
Why? I have to submit code to Google only after September 3, August 31
being evaluation deadline.
I'm following what has been said on mailing lists, and is on the web at
http://code.google.com/opensource/gsoc/2008/faqs.html#0.1_timeline
i.e. that August 18 is the firm pencils down date when I have to start
looking at what you have done and writing an evaluation. So after that
point my enthusiasm for pulling new changes from CVS and making them
compile drops very rapidly. As I said, it doesn't stop you in any way
from sorting out the code, but I'm likely to keep the first CVS snapshot
after that date that works and use that for evaluation purposes, so any
changes after that date won't be fully reflected in the evaluation,
which I have to complete by the 1st of September. As the weekend 30/31st
August is going to be a busy one for me and I will be at work on the
1st, I will be trying pretty hard to finish the evaluation by the 29th
of August.
Post by LRN
I have one (radio station, not ogg file!). I'll try to make multistream
Ogg and see how it is imported now.
I'm using this for testing:
http://www.thedividingline.com/archives/ssarchive.ogg
mplayer plays it fine using ffmpeg's decoder (and pops up title and
artist changes on each new stream).

If I open the file with "FFmpeg Compatible Files" then I get no question
about streams, it claims it will take about an hour to import, but
completes quickly having imported only the first stream (which is about
70 seconds long).

If I open with "Ogg Vorbis Files" then I get your "Select stream(s) to
import" dialogue (good!). If I select Index [00] and click OK, then I
get the "Importing ffmpeg compatible files" dialogue, which claims it
will take 33 minutes, then completes after a few seconds with the right
stream imported. Looks good, apart from the incorrect progress. Seems
odd that ffmpeg is doing the decoding, even though I thought I was
getting the libogg decoder.

Now lets try and get the second stream that way. Select Index[01]. The
dialogue box goes away and immediately comes back again with no error
message. That's odd. Maybe it didn't register properly. So I click OK
again, with the same selection. This time I get an importer dialogue,
but the first stream (index 00) is imported. Uh?

Log messages:
21:00:26: Item 320: path=/lib/ld-2.6.1.so , name=ld-2.6.1.so
21:00:26: Item 321: path=/lib/ld-2.6.1.so , name=ld-2.6.1.so
21:00:26: Trying to load avcodec and avutil
21:00:26: Loading avcodec from /usr/lib/libavcodec.so.51.57.2
21:00:26: Loading avutil from /usr/lib/libavutil.so.49.7.0
21:00:26: Importing symbols...
21:00:26: All symbols loaded successfully. Initializing the library.
21:00:26: Retrieving library version.
21:00:26: Version is 0x333902, which means 51.57-2
21:00:26: Libraries loaded successfully!
21:00:27: Container start_time = 0, that would be 0 milliseconds.
21:00:27: Stream 0 start_time = 0, that would be 0.000000 milliseconds.
21:00:27: Error: [vorbis @ 0xb41ef270] Not a Vorbis I audio packet.

21:00:27: Error: [vorbis @ 0xb41ef270] Not a Vorbis I audio packet.

21:00:27: Error: [vorbis @ 0xb41ef270] Not a Vorbis I audio packet.

Maybe there is something fishy in that section of the file. Let's try
stream 02. Exact same symptoms, resulting in the import of stream 00.
Same log messages as before.

Richard
LRN
2008-08-06 01:11:58 UTC
Permalink
Post by Richard Ash
Post by LRN
Fixed
Compile errors are indeed gone.
I've noticed one warning that is a result of code changes elsewhere you
might want to deal with: project.GetRate() now returns a double, not an
integer.
export/ExportFFmpeg.cpp:2281: warning: converting to ‘int’ from ‘double’
which suggests that the sample rate member of the class should be
double, except that that has knock on effects.
In practical terms fractional rates won't work in ffmpeg, so you have to
round to nearest integer somewhere, you just need a decision (and a
cast) as to where.
GetRate() is used only once - in ExportFFmpeg.cpp:2281. I don't see a
problem.
mSampleRate = (int)project->GetRate(); // that would be ok?
Post by Richard Ash
Back where we were, which was AAC export. It's looking a lot better now
- I can't break it badly. The quality I select has an effect on the file
I get, and if I try to choose a low quality at a high sample rate, it
asks for a valid sample rate. The dialogue is now usable. I agree it
could be nicer, but I have no idea how to achieve that - anyone else any
ideas?
H-m-m...replace wxSlider with wxSpinCtrl?
Post by Richard Ash
I think I agree with Gale that a smaller scale on the slider might be
more intelligible. Is there any particular reason for -1 to 500 as the
scale?
See my answer to Gale.
Maybe it is possible to collect statistics and point out -aq value that
gives AAC file without audible quality losses. And assign a few more
points as "noaudibleloss*0.5", "noaudibleloss*0.8" and
"noaudibleloss*0.3", etc. But that's subjective.
I don't know what's the effect on non-stereo files. Maybe same -aq
results in the same per-channel-bitrate when exporting in any number of
channels...Or same global bitrate. I'll test that.
Post by Richard Ash
Post by LRN
I have one (radio station, not ogg file!). I'll try to make multistream
Ogg and see how it is imported now.
http://www.thedividingline.com/archives/ssarchive.ogg
mplayer plays it fine using ffmpeg's decoder (and pops up title and
artist changes on each new stream).
If I open the file with "FFmpeg Compatible Files" then I get no question
about streams, it claims it will take about an hour to import, but
completes quickly having imported only the first stream (which is about
70 seconds long).
No question -> no multiple streams detected at the opening time. I am
not an expert, but as far as i know Ogg supports 2 kinds of
multiplexing: chaining and grouping.
Grouping is the same kind of multiplexing as the one used in video
containers. It requires each stream to put one initial page at the
beginning of the file. After that pages may occur in any order or do not
occur at all (except one terminal page for each stream at any point,
which is required). If Ogg file is grouped, then it is possible to read
pages starting from the first one and collect stream serial numbers
until you hit non-unique stream serial number (i.e. the page you read
belongs to a stream for which you already read initial page). This way
you'll get number of streams by reading just the beginning of the file.
Chaining means that only one stream is preset at the time. First page of
next stream only appears after terminal page of current stream.
Obviously, detecting all streams would require a library to read the
whole file.
It is possible to mix chained and grouped streams in one file, for
examples: <str1 init>...<str1 term> <str2 init> ... <str2 term> ...
<str3 init> <str4 init> <str5 init> ... <str4 term> ... <str3 term> ...
<str5 term> <str6 init> ... <str6 term>
Again, the whole file must be read before you know anything about all
streams.

Maybe we have different libav* versions because i'm getting stream
selection dialog from libav* after all - but it only has two streams.
I noticed that libavcodec spends <considerable> amount of time before it
shows that dialog, so i'm assuming it looks through the whole
file...strange, since it should detect all streams by doing that, not
just two.
Also, libav* logs a few "Not a Vorbis I audio packed", which suggests
that there's something else than just audio in this file (or maybe some
broken packets?)
Post by Richard Ash
If I open with "Ogg Vorbis Files" then I get your "Select stream(s) to
import" dialogue (good!). If I select Index [00] and click OK, then I
get the "Importing ffmpeg compatible files" dialogue, which claims it
will take 33 minutes, then completes after a few seconds with the right
stream imported. Looks good, apart from the incorrect progress. Seems
odd that ffmpeg is doing the decoding, even though I thought I was
getting the libogg decoder.
Now lets try and get the second stream that way. Select Index[01]. The
dialogue box goes away and immediately comes back again with no error
message. That's odd. Maybe it didn't register properly. So I click OK
again, with the same selection. This time I get an importer dialogue,
but the first stream (index 00) is imported. Uh?
As far as i can tell, if you select "Ogg Vorbis Files", importer first
tries to use libogg/libvorbis to import the file (at the very least
libogg succedes - it is able to give you the list of streams), then
(after a failure somewhere, right now i can't tell - where) it tries
each available import plugin sequentially (and because "Ogg Vorbis
Files" is still in the list of import plugins, you get another stream
selection dialog from it, but again - after that it fails somewhere)
until it hits libav*, which detects only two streams (for me) and
imports any (or both) of them at your will.

I don't have an ogg analyzer tools, so i can't tell you anything more
about this file. Yeah, it could be malformed.

I tried to pick two normal ogg files from my music collection and cat'ed
them into one file 'construct.ogg' (that is, made chained ogg, or
something close to that) like that:
cat load_MEC_music.ogg load_CH_music.ogg >construct.ogg
libav* spends some time looking through the file (i have a breakpoint in
av_log_wx_callback and can see that it logs some info three times before
it shows stream selector) and finds both streams.
libogg/libvorbis imports it without problems too (though progress dialog
behaves strangely).

Mixed 5 streams is the same manner (2 streams from previous two files
and 3 more).
libav* spends some time analyzing the file and detects 3 streams (and
stream indices in stream selection are broken)
libogg/libvorbis detects and imports any stream (again, progress dialog
only shows the progress for first stream, then it stays at the maximum
until all remaining streams are imported).
Gale Andrews
2008-08-05 07:53:23 UTC
Permalink
Hi LRN

Sorry I have not had much time to test all this yet... maybe next few
days.

Some things so far in the export window:

* Options for "Custom ffmpeg export" and "WMA..."
point to "Specify AMR-NB Options"

* "WAV files (FFmpeg)" still exists ?

* Re the AAC quality slider, how are we to explain this to the users -
what are the reference points (e.g. against iTune's quality
presets) given this seems to be a very non-standard way of setting
the quality? What is the meaning of "-1"? Do the 502 possible
gradations give a misleading sense of accuracy, and mightn't
something very much simpler (such as four or five "target" bit rates)
be more understandable?

* I think we must say somewhere that all these AAC settings are LC
profile only (best done in the filter itself)?

You said "FFmpeg importer now handles start_time. Correctly? I do not
know..." I was not aware of a problem, but what should we look out for?
This is the start time of audio being modified when the file is imported?


Thanks

Gale
LRN
2008-08-06 00:04:04 UTC
Permalink
Post by Gale Andrews
Hi LRN
Sorry I have not had much time to test all this yet... maybe next few
days.
* Options for "Custom ffmpeg export" and "WMA..."
point to "Specify AMR-NB Options"
Damn. Hiding AMR was a bad idea after all. I think i'll revert back that
feature.
Post by Gale Andrews
* "WAV files (FFmpeg)" still exists ?
It will be the last one to be removed. Since WAV-distortion bug is still
there (isn't it?), alternative WAV exporter could come in handy.
Post by Gale Andrews
* Re the AAC quality slider, how are we to explain this to the users -
what are the reference points (e.g. against iTune's quality
presets) given this seems to be a very non-standard way of setting
the quality? What is the meaning of "-1"? Do the 502 possible
gradations give a misleading sense of accuracy, and mightn't
something very much simpler (such as four or five "target" bit rates)
be more understandable?
"-1" - automatic quality
I can't say anything about reference points. Quality from 0 to 500
covers all bitrates (try exporting at each quality level, and you'll get
files of different sizes each time).
I thought about scaling it down to 0-100, but i like things to be
explicit: ffmpeg itself accepts -aq=0..500 for -acodec=libfaac, so
should Audacity.
Post by Gale Andrews
* I think we must say somewhere that all these AAC settings are LC
profile only (best done in the filter itself)?
Maybe.
Post by Gale Andrews
You said "FFmpeg importer now handles start_time. Correctly? I do not
know..." I was not aware of a problem, but what should we look out for?
This is the start time of audio being modified when the file is imported?
/**
* Decoding: pts of the first frame of the stream, in stream time base.
* Only set this if you are absolutely 100% sure that the value you set
* it to really is the pts of the first frame.
* This may be undefined (AV_NOPTS_VALUE).
* @note The ASF header does NOT contain a correct start_time the ASF
* demuxer must NOT set this.
*/
int64_t start_time;

That's the only thing i know. I also know that start_time/AV_TIME_BASE =
seconds.
Gale Andrews
2008-08-06 08:26:40 UTC
Permalink
|
LRN
2008-08-06 08:40:43 UTC
Permalink
One minor issue: after chosing "WAV files (FFmpeg)" for export, when I
go back to export, the filter is preset to "WAV Microsoft 16 bit PCM".
That is because both libsndfile's 16bit pcm export type and FFmpeg's
16bit pcm export type are added to the list under the name "WAV". To fix
it one has to change the format names in ExportFFmpeg.cpp (lines
111-119). It's easy to fix and will have no ill consequences (i think).
However, since using libsndfile, libmp3lame and others is preferred, i
kept this behaviour. Well, i won't last long anyways - "WAV Files
(FFmpeg)" will be gone soon, and after that there will be no formats
with identical names.
LRN
2008-06-22 17:43:30 UTC
Permalink
Post by Richard Ash
I would suggest "Default WAV" pointing to 16-bit PCM WAV and "Default
AIFF" pointing to 16-bit AIFF as convenience entries for people creating
CDs, the rest all go into the uncompressed types entry (if people want
other sorts of WAV / AIFF they would do them by clicking options from
"other", I wouldn't want Default WAV to be changeable to some other bit
depth, because in a lot of software there is only one sort of WAV - 16
bit.
Done.
Gale Andrews
2008-06-22 18:23:27 UTC
Permalink
|
Continue reading on narkive:
Loading...