Welcome to Doom9's Forum, THE in-place to be for everyone interested in DVD conversion.

Before you start posting please read the forum rules. By posting to this forum you agree to abide by the rules.

 

Go Back   Doom9's Forum > Programming and Hacking > Development

Reply
 
Thread Tools Search this Thread Display Modes
Old 22nd February 2011, 06:15   #161  |  Link
lethedoom
Registered User
 
lethedoom's Avatar
 
Join Date: Dec 2010
Location: california
Posts: 23
thank you for the technical explanation.
lethedoom is offline   Reply With Quote
Old 22nd February 2011, 11:19   #162  |  Link
Przemek_Sperling
Registered User
 
Join Date: Jun 2009
Location: Poland
Posts: 125
Thank you very much. Everything works great!

BTW, can anyone explain me why newer Ogg encoders produce significially larger files than the older ones? I compared files produced by LameXP 3.18, LameXP 4.00, and jetAudio 8.0.11. I encode music at Q8 (e.g. Mana - "Arde el Cielo - Vivo"). The sizes of the compressed CD are: LameXP 3.18 - 130 megabytes, LameXP 4.00 - 158 megabytes, and jetAudio 8.0.11.1600 - 159 megabytes.
Przemek_Sperling is offline   Reply With Quote
Old 22nd February 2011, 15:41   #163  |  Link
tipsypenguin
Registered User
 
Join Date: Mar 2005
Posts: 50
Quote:
Originally Posted by LoRd_MuldeR View Post
Please check the file again at http://www.virustotal.com/, just to be sure, and then report the FALSE POSITIVE to the developer of the a/v software.
I reported the false positive to Symantec and they are going to remove the detection from within their products . an update will be distributed in the next set of virus definitions.

Thanks for the new LameXP
tipsypenguin is offline   Reply With Quote
Old 22nd February 2011, 20:44   #164  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by mariush View Post
Oh wow... hey, thanks i guess but no need to tell me, I'm not a mod or admin here. I just told you because I know the mods here are somewhat paranoid and start to ban people or close threads just for saying "torrent" or "downloaded" (even though he may have PURCHASED and downloaded and wants to re-encode for his own backup).
If he had purchased the stuff, he wouldn't download it "from bittorrent sites". Nor does this sound like he tries to make a backup

Also this has nothing do with "paranoia". This forum has clear rules that all users accept when signing up. And the job of the moderators is to uphold these rules.

The sensitivity for "warez" is high, yes. And that's for good reason. We don't want that the people who are running this board get into serious trouble!

But if a user thinks his post/thread was removed/closed for no good reason, then he can always send a PM to the moderator in order to clarify the situation...


Quote:
Originally Posted by mariush View Post
http://code.google.com/p/ac3filter/s...cpp?repo=valib

line 35. Add some parameter to switch between old style or new style wave file on creation and if old style is selected, then don't write the junk header in the first place? You already modified it to support unicode so why not add a command line switch like -format=auto,old,force-64bit etc...

Isn't the app aware or can't it compute the final length before it outputs the wav file to disk?
The decision between "old style" and "new style" (RF64) Wave files is done when the file is closed, because prior to that point the Wave writer can't know if the final size will be above 4 GB or not.

In any case the 'JUNK' chunk has to be written at the beginning of the file, because we must be prepared for writing the "ds64" chunk later, if necessarily.

And to make this clear again: When the final size is below 4 GB, then ValibDec writes a perfectly valid RIFF/Wave file. The 'JUNK' chuck doesn't matter, as all reading application must ignore that chunk.

It is evident that that applications which fail to read the Wave file just because of the additional 'JUNK' chunk are broken!

Consequently the one and only question here is: Do we care enough about these broken applications to implement a workaround? Or should we encourage the authors to fix their RIFF/Wave parsers?

(If we modified the Wave writer to not write the 'JUNK' chunk, we couldn't turn the file into a RF64 file later anymore, which means we would kill support for output files larger than 4 GB)


Quote:
Originally Posted by tipsypenguin View Post
I reported the false positive to Symantec and they are going to remove the detection from within their products . an update will be distributed in the next set of virus definitions.

Thanks for the new LameXP
Well done


Quote:
Originally Posted by Przemek_Sperling View Post
BTW, can anyone explain me why newer Ogg encoders produce significially larger files than the older ones? I compared files produced by LameXP 3.18, LameXP 4.00, and jetAudio 8.0.11. I encode music at Q8 (e.g. Mana - "Arde el Cielo - Vivo"). The sizes of the compressed CD are: LameXP 3.18 - 130 megabytes, LameXP 4.00 - 158 megabytes, and jetAudio 8.0.11.1600 - 159 megabytes.
Well, I assume you are using the "quality-based" (VBR) rate-control mode, as with the "bitrate-based" (ABR) mode the resulting file size would be defined solely by the chosen target bitrate.

The differing output sizes with VBR mode can be explained by different versions of OggEnc (libvorbis) being used. However comparing only the file sizes between the different versions doesn't tell you anything!

Instead you would have to adjust the VBR values, until both files have the same file size again. Then (and only then) you can compare the sound quality and decide which version is better...

(Alternatively you could adjust the VBR values until both files have the same sound quality and then compare the files sizes. But that's probably hard to do ^^)
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 23rd February 2011 at 12:33.
LoRd_MuldeR is offline   Reply With Quote
Old 22nd February 2011, 21:49   #165  |  Link
mariush
Registered User
 
Join Date: Dec 2008
Posts: 589
What I'm saying is that since you're modifying that tool to add Unicode support, you could in theory add a switch in the command line options (or some way to pass this to the tool, not sure how your app interacts with it), so that the tool will "TRUST" you that the output wav file will NOT exceed 4 GB or whatever the limit is. If the flag/switch in the command line is missing, just work like it works now. You should be able to determine based on number of seconds and channels the mp3/ac3/etc how much data you will have so you could pass this switch safely for files you know they won't reach that limit.

So if you pass that flag, let's say "-force-old-wav", the wav output class/whatever stores it, does not write the junk bytes at all and when closing the file, if the actual data is larger that what's allowed, enter the maximum allowed.

If total length and data is smaller than the limit for the format, it will play on all software, no junk, no ds64 chunk
if total lenght and data is larger, it will still play on all software, no junk or ds64 chunk but the data in the header will record the maximum number of samples allowed (basically truncating everything over max samples). So the rest of the data in the wav file would be ignored by players (not sure, maybe you'd need to seek to the end of the maximum samples and write there the ending for the chunk).
mariush is offline   Reply With Quote
Old 22nd February 2011, 22:32   #166  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by mariush View Post
What I'm saying is that since you're modifying that tool to add Unicode support, you could in theory add a switch in the command line options (or some way to pass this to the tool, not sure how your app interacts with it), so that the tool will "TRUST" you that the output wav file will NOT exceed 4 GB or whatever the limit is. If the flag/switch in the command line is missing, just work like it works now. You should be able to determine based on number of seconds and channels the mp3/ac3/etc how much data you will have so you could pass this switch safely for files you know they won't reach that limit.

So if you pass that flag, let's say "-force-old-wav", the wav output class/whatever stores it, does not write the junk bytes at all and when closing the file, if the actual data is larger that what's allowed, enter the maximum allowed.

If total length and data is smaller than the limit for the format, it will play on all software, no junk, no ds64 chunk
if total lenght and data is larger, it will still play on all software, no junk or ds64 chunk but the data in the header will record the maximum number of samples allowed (basically truncating everything over max samples). So the rest of the data in the wav file would be ignored by players (not sure, maybe you'd need to seek to the end of the maximum samples and write there the ending for the chunk).
Yes, it should be possible to add such an option.

Still that option would only be helpful as a workaround for broken reading applications, which do not handle the 'JUNK' chunk as they are supposed to

Fortunately most applications are not broken in this regard. So I currently think this wouldn't be worth the effort.

Especially when considering that, in case you really encounter one of the broken applications, the solution is very easy: Re-save the file with SoX once and that's it.

Probably I will add a short note about this issue to the F.A.Q. document and then let the matter rest... [EDIT] Done! [/EDIT]
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 23rd February 2011 at 15:46.
LoRd_MuldeR is offline   Reply With Quote
Old 22nd February 2011, 22:50   #167  |  Link
mpucoder
Moderator
 
Join Date: Oct 2001
Posts: 3,530
Now that I am aware of the reason for the junk chunk prior to the fmt chunk I'll begin modifying versions of MuxMan starting with the Pro version, then back-stitched to the free version.
mpucoder is offline   Reply With Quote
Old 23rd February 2011, 00:21   #168  |  Link
manolito
Registered User
 
manolito's Avatar
 
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,078
@mpucoder,

thank you very much, looking forward to the new version...

Cheers
manolito
manolito is offline   Reply With Quote
Old 23rd February 2011, 07:38   #169  |  Link
ckmox
Registered User
 
Join Date: Feb 2009
Posts: 136
thanks a lot for the final release
ckmox is offline   Reply With Quote
Old 24th February 2011, 00:48   #170  |  Link
IgorC
Registered User
 
Join Date: Apr 2004
Posts: 1,315
Any particular reason for including unstable alpha to supposedly stable and final GUI?

LAME 3.99a is on heavy alpha development and far from any beta release right now. It's untested.
No warning or any message for user? No choice between stable 3.98.4/unstable 3.99?


A huge thanks for the final release.

Last edited by IgorC; 24th February 2011 at 00:51.
IgorC is offline   Reply With Quote
Old 24th February 2011, 01:05   #171  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by IgorC View Post
Any particular reason for including unstable alpha to supposedly stable and final GUI?

LAME 3.99a is on heavy alpha development and far from any beta release right now. It's untested.
No warning or any message for user? No choice between stable 3.98.4/unstable 3.99?

A huge thanks for the final release.
I need to use LAME v3.99, because that versions handles Unicode file names and Unicode tags on the Windows platform. The older 3.98 version did not...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 24th February 2011 at 01:09.
LoRd_MuldeR is offline   Reply With Quote
Old 24th February 2011, 10:56   #172  |  Link
olnima
Registered User
 
olnima's Avatar
 
Join Date: Dec 2003
Posts: 216
But - are there any reasons against a manual update to 3.99a13?

Two steps nearer to first beta...

Thanks for LameXP,
Olnima
olnima is offline   Reply With Quote
Old 24th February 2011, 12:14   #173  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by olnima View Post
But - are there any reasons against a manual update to 3.99a13?

Two steps nearer to first beta...

Thanks for LameXP,
Olnima
The last time I checked (before the LameXP v4.00 release), the latest tag in LAME's CVS repository was "lame3_99alpha11". Consequently that was the version I built. I just checked again and there is a "lame3_99alpha12" tag now (and HEAD is developed as 3.99a13 currently). But since my time machine is currently out of order, I will update to the latest LAME tag in the next LameXP release version.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 24th February 2011 at 12:24.
LoRd_MuldeR is offline   Reply With Quote
Old 24th February 2011, 12:37   #174  |  Link
IgorC
Registered User
 
Join Date: Apr 2004
Posts: 1,315
about LAME 3.99 alpha
http://www.hydrogenaudio.org/forums/...dpost&p=744961

since alpha_12 newer --vbr--new is set by default.
Last alpha 13 is here http://www.rarewares.org

btw, Mulder, if you are interested there is a new version of Aotuv Vorbis with a lot of tunings.

Last edited by IgorC; 24th February 2011 at 12:46.
IgorC is offline   Reply With Quote
Old 24th February 2011, 12:46   #175  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by IgorC View Post
btw, Mulder, if you are interested there is a new version of Aotuv Vorbis with a lot of tunes.
Already included:
http://lamexp.git.sourceforge.net/gi...3c5d3e5b563617
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊
LoRd_MuldeR is offline   Reply With Quote
Old 24th February 2011, 12:52   #176  |  Link
IgorC
Registered User
 
Join Date: Apr 2004
Posts: 1,315
Wow, that was fast.

There was important bugfix 6.01.
IgorC is offline   Reply With Quote
Old 24th February 2011, 14:56   #177  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
New snapshot available:
http://sourceforge.net/projects/lame...A)/2011-02-25/
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 25th February 2011 at 02:12. Reason: Bugfix
LoRd_MuldeR is offline   Reply With Quote
Old 25th February 2011, 05:08   #178  |  Link
IgorC
Registered User
 
Join Date: Apr 2004
Posts: 1,315
Great, thank you for fast updates.
IgorC is offline   Reply With Quote
Old 25th February 2011, 13:41   #179  |  Link
olnima
Registered User
 
olnima's Avatar
 
Join Date: Dec 2003
Posts: 216
Quote:
Originally Posted by LoRd_MuldeR View Post
The last time I checked (before the LameXP v4.00 release), the latest tag in LAME's CVS repository was "lame3_99alpha11". Consequently that was the version I built. I just checked again and there is a "lame3_99alpha12" tag now (and HEAD is developed as 3.99a13 currently). But since my time machine is currently out of order, I will update to the latest LAME tag in the next LameXP release version.

I meant, if the updating of lame.exe could be done by the users or if You have any reasons not to recommend this.
You do not need a time machine for that.
olnima is offline   Reply With Quote
Old 25th February 2011, 14:02   #180  |  Link
LoRd_MuldeR
Software Developer
 
LoRd_MuldeR's Avatar
 
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
Quote:
Originally Posted by olnima View Post
I meant, if the updating of lame.exe could be done by the users or if You have any reasons not to recommend this.
You do not need a time machine for that.
Generally it wouldn't be a very good idea to encourage "Newbie" users to replace the built-in LAME encoder with an arbitrary build that hasn't been tested to cooperate with GUI properly. There are all kinds of problems that might occur. At the same time "Advanced" users who can't wait for the next update and who know what they are doing can make their own builds at any time (the advantage of OSS).
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊

Last edited by LoRd_MuldeR; 25th February 2011 at 14:20.
LoRd_MuldeR is offline   Reply With Quote
Reply

Tags
aac, aotuv, flac, lame, lamexp, mp3, mp4, ogg, oggenc, opus, vorbis

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +1. The time now is 12:31.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2024, vBulletin Solutions Inc.