Created attachment 1091
ID3 tags in Nautilus
Nautilus also displays the tags including the year tag.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/691233
Title:
mp3 export fails to save id3 tags
T
As for the "id3" command, that supports ID3v1.1 only and we don't write
those tags.
So, I think we either fixed Audacity or the other applications were
fixed and I think we can close this bug.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to U
Created attachment 1090
ID3 tags in Dolphin
This shows that Dolphin does indeed (at least now it does) recognized
the Audacity tags. One note about this is that you HAVE to enable
"baloo" which the file indexer that collects this extra information.
Without it enabled, you do see metadata from any
Steve, can I get you to try this again as portaudio has been upgraded.
I have not gotten it to freeze, but I do get strange results with pulse.
I have 32-tracks of Chirp and if I have the "pulse" device selected, the
first time I Play it sound just fine. But I get a lot of skipping of
the playbac
(In reply to comment #22)
> (In reply to comment #16)
> >>> (In reply to comment #13)
> >>> Leland wrote:
> >> It definitely wouldn't hurt to validate both Linux AND Windows since they
> >>> now share the same code.
> >> On Win 7 (audacity.cfg and plugin*.cfg files deleted before launching
> >> HE
(In reply to comment #17)
> I tried the current svn head on Ubuntu 14.10 with wxgtk 3.0 (./configure
> --disable-dynamic-loading && make) and ran these commands in the build tree:
>
> ./audacity testfile.ogg
> ./audacity testfile.flac
>
> When I run the second command, the second audacity sends a
(In reply to comment #15)
> (In reply to comment #13)
> Leland wrote:
> > It definitely wouldn't hurt to validate both Linux AND Windows since they
> > now share the same code.
> On Win 7 (audacity.cfg and plugin*.cfg files deleted before launching HEAD),
> using Explorer "Open with" to open an AUP
Just committed the fix for this. It was based on Tobias's patch, but
his patch didn't properly exclude wxMac.
And Benjamin was correct, there was a crash when the "running" Audacity
attempted to disconnect the socket. Took me nearly all day to figure
out what the heck was going on.
Basically, t
Fix committed in r13873
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/615307
Title:
opening a file from file manager when audacity is open gives error
message
To manage notifications about this b
(In reply to comment #17)
> I tried the current svn head on Ubuntu 14.10 with wxgtk 3.0 (./configure
> --disable-dynamic-loading && make) and ran these commands in the build tree:
>
> ./audacity testfile.ogg
> ./audacity testfile.flac
>
> When I run the second command, the second audacity sends a
(In reply to comment #20)
> (In reply to comment #19)
> > Both (unrelated) issues have been correct in r13854 and r13855.
>
> Confirmed. Both work now, but I found a not-working corner case. When you
> launch a second audacity without specifying a file, another assertion is
> triggered:
>
> $ ./a
(In reply to comment #101)
> Are we providing FFmpeg 0.6 binaries for Win/Mac for 1.3.13 Beta?
This might be something that the devel subscribers would like to discuss.
Personally, I say go for it...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscri
Okay. So I'm going to go ahead and commit the version 11. Gale and I will
work out what the M4A options should be as a separate patch since that will
take some discussion and testing.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
h
(In reply to comment #92)
> Leland, do you think the reason LRN went for quality was because FFmpeg has a
> problem if you simplistically specify the bit rate? Although users don't
> like/understand those quality settings, they seem to be functional - higher
> quality = higher bit rate. Can you se
(In reply to comment #88)
> Tried v12 on win 7 x64 so far. Main finding so far is that exported bit rates
> are not correct. Exporting a stereo music track, both with FFmpeg 0.5 and 0.6
> and according to Medianfo and iTunes,
>
> 24 kbps exports as 60 kbps
>
> 96 and 256 kbps both export as 150
(In reply to comment #89)
> Scanned the patch. Nice work with the function declaration macros, made it a
> lot more readable. And your changes are well documented.
>
> Why change several wxLogDebug() calls to wxLogMessage()? I would think that
> type of info would only be clutter to most users, a
Created an attachment (id=153)
Change m4a export options to bitrate
This changes the m4a export options to a more common bitrate instead of
quality.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/60293
(In reply to comment #81)
>
> Does this cover everything?
>
I believe so. Let's get the v11 patch committed to get it into the hands of
more users and more environments to see if there's more issues.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscr
(In reply to comment #83)
> So whoever commits the bug can resolve it fixed because it has had its QA
> testing already. Thanks, Leland.
Is this supposed to wait until after 1.3.13 is released? Or should it get
committed now?
--
You received this bug notification because you are a member of Ubu
(In reply to comment #79)
> AAC export on Ubuntu (native encoder using "M4A files") is still wrong - seems
> to be a silent file - "playable" but very small file size. Are we still
> expecting that?
I'm pretty sure the small file size is expected, but the silent file is not.
Can you send me one o
(In reply to comment #77)
> Is the new FFmpeg support in these patches backwards-compatible beyond 0.5? So
> if someone on Win went from 1.3.6 Beta to 1.3.13 Beta, they would not need to
> update their FFmpeg? I don't think it matters if not, just asking.
Probably not. I only tested as far back a
Created an attachment (id=147)
Don't just bypass the metadata dialog, bypass writing the tags too!!!
This skips writing the tags if they aren't supported by the format. It was
only a one line change, so "major" testing shouldn't be required.
--
You received this bug notification because you are
(In reply to comment #74)
> My only issue was with the stereo m4a I exported using Ubuntu's FFmpeg so
> using
> the native aac encoder. This is the log when importing it into Audacity with
> either version of Audacity:
> Error: Stream 0 start_time = 0, that would be 0.00 milliseconds.
>
I
(In reply to comment #70)
> (In reply to comment #69)
> Thanks Leland. Will try v10. For those who try the patches one after the
> other,
> is there an easier way to apply the patch than manually deleting then
> restoring
> the affected files before patch? E.g. could I actually apply your v10 pat
(In reply to comment #72)
> 2. Use svn revert to revert the changes.
Oooo, I like that one. Didn't know about it. I'll have to give that a try
next time.
Thanks,
Leland
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs
Created an attachment (id=142)
Reuploading v10 patch...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/602934
Title:
ffmpeg import/export not working with ffmpeg version in maverick
--
ubuntu-bugs
(In reply to comment #64)
> AC3 import OK. AC3 export gives a zero byte file but the same happens with
> standalone ffmpeg at the command line "LIBAVUTIL_50 not defined in file
> libavutil.so.50 with link time reference". I gather I may have to find
> libavcore, from Googling the error?
>
Not sure
Created an attachment (id=140)
Forces usage of ac3-fixed encoder
I took the easy way out and forced usage of the "ac3-fixed" encoder.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/602934
Title:
ffm
(In reply to comment #61)
> I won't be trying v7 for a while so if you are around please let me know what
> you think about the above error.
It's because your building with system libraries. I have not tried that since
I added HEAD support. I will see what I can do to get it to build using syst
Created an attachment (id=141)
AC3 encoder should be detected for all versions now
Okay, this one should detect the proper AC3 codec for FFmpeg HEAD and older
versions.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.laun
(In reply to comment #66)
> Created an attachment (id=140) [details]
> Forces usage of ac3-fixed encoder
>
> I took the easy way out and forced usage of the "ac3-fixed" encoder.
And the easy way was (at least the way I did it) was stupid. I'll work on this
again when I get home tonight.
--
You
Created an attachment (id=139)
Yet another patch...
Okay, this one should allow building again the FFmpeg HEAD headers. The last
couple of patches allowed Audacity to use FFmpeg HEAD libraries, but not build
against the headers. I'd left out a bit of Benjamin's original patch...
This also preve
Created an attachment (id=138)
Add WMA metadata support for later FFmpeg versions
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/602934
Title:
ffmpeg import/export not working with ffmpeg version in
Created an attachment (id=137)
Add WMA metata support for later FFmpeg versions
This patch includes a fix for bug #134 where WMA tag support was missing. It
was fixed on 2010-02-15, so if a libavformat with a version greater than
52.52.0 is used with Audacity, then WMA tags can be specified.
Lel
(In reply to comment #55)
> I ran into
>
> ImportFFmpeg.cpp
> ..\..\..\src\import\ImportFFmpeg.cpp(874) : error C3861: 'lrintf': identifier
> not found
> ..\..\..\src\import\ImportFFmpeg.cpp(878) : error C3861: 'lrint': identifier
> not found
>
> on Windows Unicode Release.
Sorry about that Gal
Created an attachment (id=135)
Provides support for later versions of FFmpeg
This provides all of the previous changes, plus:
1) On import, if the sample format from FFmpeg is 8-bit or 16-bit, then it
will be imported into Audacity as 16-bit. Anything else gets imported as
float.
2) Export opt
(In reply to comment #52)
> (In reply to comment #48)
> > newer FFmpegs include a native amr decoder and the default sample format
> > for
> > them is float whereas the default for the opencore amr decoder it 16-bit.
> Thanks for the new patch. Yes I recall now about FFmpeg only supporting 16-bi
Created an attachment (id=134)
Now includes support for non 16-bit input samples
I would like to have tested this a tad more, but I have to get to work and I
wanted to get it out before I left.
This adds support for input sample formats other than 16-bit and should correct
that amrnb problem.
Le
So the issue is that Audacity doesn't support any sample formats from FFmpeg
other than 16-bit. So audio from decoders that do not output 16-bit samples
will not import properly into Audacity.
You may prove it by creating a WAV file in 32-bit float format. Then try
importing it. Make sure you h
Forgot to mention that this problem existed in at least 1.3.12, so it's not a
new issue...
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/602934
Title:
ffmpeg import/export not working with ffmpeg ve
(In reply to comment #46)
> AMR narrowband appear to be exported correctly, but when imported the file is
> double the original length and at half the original frequency.
This is because the newer FFmpegs include a native amr decoder and the default
sample format for them is float whereas the defa
Created an attachment (id=132)
Provides support for later versions of FFmpeg and HEAD
An update to the patch that should work for our existing 0.5x up through
HEAD...though HEAD should be tested a bit more.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is s
(In reply to comment #41)
> (In reply to comment #39)
> > use libfaac for encoding (Windows and OSX) and use the native FFmpeg aac
> > decoder instead of libfaad
> OK, I think we could get away with that on Windows and OS X without a release
> note if there are no technical issues with it. I assum
(In reply to comment #41)
> Added note to "current issues" about SVN FFmpeg.
How important is HEAD support? The reason I ask is that they have changed
things around a bit in the library (on 2010-06-22, my 25th wedding anniversary
;-)) and have "broken" a kludge we had in place to support Unicode
(In reply to comment #37)
> (In reply to comment #36)
> > if everyone is also satisfied, I'd like to go ahead and commit it and move
> > on to the detection simplification.
> If you're OK I'd still like to try with SVN FFmpeg, since that gave endless
> trouble before. I assume you have done this, b
(In reply to comment #38)
> Yet another (and I'm trying it now), would be to have both the native and
> libfaac/libfaad enabled (Windows and OSX). It may be possible to present both
> options to the user. It's certainly possible via the ffmpeg command, but via
> the custom ffmpeg options dialog,
(In reply to comment #32)
> (In reply to comment #31)
> >> I think you will be able to repro it on Windows (and I assume on FFmpeg
> >> 0.6.1
> >> too, but I have not tried with 0.6.1 yet). What happens on Mac?
> >
> > Same sort of thing. If I create a mono M4A file using 0.6.1 and then try to
(In reply to comment #37)
> I don't see we can do a "Stereo Tracks to Mono" on an M4A imported via libfaad
> as it would take too long. But could or should you do some hackage in our
> FFmpeg code so that it imports "first time" as mono? I think the answer to
> that
> is "is this a libfaad bug"? I
I have FINALLY figured out, at least for me, why the m4a files would import as
mono when the above patch was NOT applied. It basically boils to me being an
idiot.
When I was originally testing the patch, I'd realized that the QuickTime
importer was doing the import, so I reversed the order of the
(In reply to comment #34)
> (In reply to comment #33)
> > 1) No extreme time differences between m4a and other ffmpeg formats.
> > 2) The native exporter is faster than faac
> > 3) Faac exported files sound better
> > 4) Any file imported with faad gets imported as stereo
> > This was all done
(In reply to comment #27)
> I think you will be able to repro it on Windows (and I assume on FFmpeg 0.6.1
> too, but I have not tried with 0.6.1 yet). What happens on Mac?
>
Same sort of thing. If I create a mono M4A file using 0.6.1 and then try to
import it using a v0.5 library, it will alway
Created an attachment (id=126)
Just a combination of 0.6.1 support and the import crash fix - try 2 :-)
Re-recreated the patch. :-)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/602934
Title:
ffmp
(In reply to comment #23)
> That OGG slowness thing is separate (bug 311) but I have never seen it so
> far.
>
> Why would the copy-in Pref affect OGG > OGG? Audacity should copy the OGG in
> irrespective of that setting.
I'll respond in bug #311.
Leland
--
You received this bug notification
(In reply to comment #28)
> (In reply to comment #26)
> > Created an attachment (id=125) [details] [details]
> > Just a combination of 0.6.1 support and the import crash fix
> Actually this patch lacks the three new files in lib-src\ffmpeg\libavutil
>
Oops, sorry about that. Will create it again
Created an attachment (id=125)
Just a combination of 0.6.1 support and the import crash fix
This is a combined patch that include the 0.6.1 support and the fix for the
import crash from bug #317.
I have been unable to pin down why M4A imports are silenced. Actually, I no
longer see this, so if y
For those experiencing slow exports after importing an OGG file, can you try
changing "Edit->Preferences->Import/Export->Read uncompressed..." to "Make a
copy..." and then exit Audacity, get back in, and try to reproduce the
slowness.
For me, it no longer occurs. And since the slowness happens wi
Okay, I'm getting kind of confused. Is this working for anyone at all? Should
I regenerate the above patch with the fix from bug #317? What are the
outstanding issues?
Leland
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://
Gale, are you still having issues with the patch? It really should affect
anything other than FFmpeg files. Could you try it against a fresh checkout?
Also, did you happen to a "make dep" in the "src" directory before/after
applying? (would be a good idea to do it.)
Leland
--
You received th
Created an attachment (id=113)
Provides support for later versions of FFmpeg
This patch provides support for the more recent versions of FFmpeg. It still
supports for the existing pre-built Windows and Mac FFmpeg binaries. It also
incorporates the fix for bug #274 and provides compile-time verif
(In reply to comment #7)
Stupid question...of course it should be fixed for MP2s as well. Fix
committed.
Leland
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/581113
Title:
Value for year property
Should this also be fixed for MP2 files as well?
Leland
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/581113
Title:
Value for year property in ID3 tags gets lost on export of mp3 file
--
ubuntu-b
61 matches
Mail list logo
