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. |
21st February 2011, 19:30 | #142 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
|
21st February 2011, 19:48 | #143 | Link |
Registered User
Join Date: Dec 2010
Location: california
Posts: 23
|
Thank you for this excellent free tool--you are my benefactor.
I see no reason to choose to use the slower 4.0 ( I did install and try the final version today ) when I have had no problems at all using the much faster 3.18--the same resources are used (100% cpu) and no hard drive problems ever occurred on my pc while using 3.18 running 8 simultaneous processes. As I am just a pedestrian computer user--neither expert nor a programmer--your arbitrary limit makes no sense to me in light of my usage experience. |
21st February 2011, 20:22 | #144 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
While I still doubt that running zillions of instances in parallel is a very good idea, I can add an option to configure the maximum number of instances in one of the future versions...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 21st February 2011 at 20:25. |
|
21st February 2011, 21:01 | #145 | Link | |||
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
Latest findings about these funny Wave files created by ValibDec:
Quote:
Quote:
Quote:
In the meantime I found that two other audio converters I frequently use also reject these Wave files: BeLight 0.2.2.0 (this is the latest version) by Kurtnoise simply refuses to load the file without any error message. HeadAC3he 0.24 a13 by Dark Avenger also does not accept these files. But it displays the following error message: "Could not find fmt chunk!" I also found an old app called StripWav which can strip extra information from a Wave file header and convert the header to the "canonical" format. This app determines: "Extra chunks: JUNK". Needless to say that the stripped file does work with MuxMan, BeLight and HeadAC3he. My conclusion: Even if these files created by ValibDec may not be technically illegal, they certainly have a very unusual header leading to an incompatibility with a couple of other applications. Cheers manolito |
|||
21st February 2011, 21:58 | #146 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
However this is not "unusual" at all: RIFF files often contain 'JUNK' chunks for padding. And, by definition of the RIFF format, a reading application must ignore/skip all the 'JUNK' chunks that it encounters! Some applications might not implement a real RIFF parser and instead expect the 'fmt' chunk ("Wave header") to be located at a hard-coded position; may it be for simplicity, laziness or nescience. But it is obvious that such applications are prone to fail on certain valid RIFF/Wave files. Consequently I think we really can't/shouldn't blame the writing application here...
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 21st February 2011 at 22:31. |
|
21st February 2011, 22:10 | #147 | Link | |
Registered User
Join Date: Mar 2002
Location: Krautland
Posts: 903
|
Quote:
|
|
21st February 2011, 23:34 | #148 | Link | |
Registered User
Join Date: Dec 2010
Location: california
Posts: 23
|
Quote:
|
|
21st February 2011, 23:53 | #149 | Link |
Registered User
Join Date: Dec 2008
Posts: 589
|
lethedoom you don't have to worry about that... both the motherboard and the cpu are designed to work at elevated temperatures for a long time, it really won't make a difference to their lives whether the cpu warms up the components or not. In fact it's better to keep the cpu at a higher yet steady temperature rather than just oscillate between cold and warmer cycles.
But it's all statistical anyway, the "life" of a cpu will drop due to temperature cycles from a few million hours to a few million hours - a few thousand - the difference is so small your cpu would be antique before it dies. ps. The majority of components sensitive to heat on a motheboard (capacitors) are rated 85-105 C - so in order for a motherboard to fail, the temperature inside your computer case would have to be around 60-70C for days (capacitors get "older" faster as temperature is closer to their highest rating) in order to weaken these components. At the normal 30-40C temperature inside the case, these last for at least 5-10 years. By that time, you'll probably change several computers. |
21st February 2011, 23:58 | #150 | Link | ||
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
I've got my Intel Q6600 for more than four years now. And this machine is running like 8-12 hours every single day. I also use this machine for video encoding, so often the CPU's is running with 100% load on all four cores for several hours! That all is with the crappy "boxed" cooler. And, as you can see, I'm still online. So the machine has not exploded yet. Moreover, running more instances in parallel in order to increase the CPU load would produce even more heat. So with your argumentation this would be the exact opposite of what you want... Quote:
On such a machine running four instances in parallel is sufficient to fully utilize the CPU. Running even more instances than (logical) cores in parallel is pointless if not counterproductive.
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 22nd February 2011 at 00:11. |
||
22nd February 2011, 00:36 | #151 | Link | |
Registered User
Join Date: Dec 2010
Location: california
Posts: 23
|
Quote:
|
|
22nd February 2011, 00:53 | #152 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
Also: Are you 100% sure that you were using the same settings (rate-control mode + LAME algorithm quality) and the same input files for both versions? Finally I don't think that the overall encoding process takes long enough to have a significant impact on the CPU temperature, unless you really process a huge number of files. And even if the temperature did increase, you wouldn't have to worry, as the CPU is designed to run under full load for a long time. If the CPU temperature ever reaches a "critical" level under load, then you should check whether the cooler in stalled correctly! Also cleaning the dust can work wonders (For clarification: Can you please post a screenshot of CPU-Z running on your computer?)
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 22nd February 2011 at 01:04. |
|
22nd February 2011, 01:44 | #153 | Link |
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
Re problematic Wave files created by ValDec:
After some more research I believe I understand the problem now. The whole thing is about the RF64 Wave format extension which was introduced by the EBU around 2006. This RF64 format is required if a Wave file gets bigger than 2GB. If an application writes a RF24 compatible Wave file, it inserts a JUNK chunk into the header. As long as the file size stays below 2 GB this JUNK chunk is just a placeholder and has no meaning, applications should ignore it. But if the size grows beyond the 2 GB limit, the RIFF header has to be replaced by a RF64 header which is bigger. This is why the JUNK chunk is needed. But of course older software (pre 2006) has no knowledge of this JUNK chunk and often throws an error. I just made some tests with WaveLab 6 which has an option to support the RF64 format (disabled by default). The results are pretty clear. With the RF64 option enabled it creates files which are not compatible with MuxMan, with the option disabled it produces compatible files. Obviously ValDec always creates RF64 enabled Wave files, I have not found an option to turn this RF64 support off. Maybe LameXP should have a checkbox "RF64 support" under the Wave output tab. If this checkbox is not checked then the output should always be piped through SoX. Cheers manolito |
22nd February 2011, 02:13 | #154 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
Still this "RF64" extension obviously was designed with backward-compatibility in mind. Therefore the additional information is stored inside a 'JUNK' chunk, which according to the RIFF specifications will be ignored/skipped by all "legacy" application, instead of modifying existing structures. So as long as the file size doesn't exceed a size of 4GB, legacy applications that don't support RF64 should still handle such files perfectly fine. And obviously most application do! Those that stumble upon the additional 'JUNK' chunk were broken from the beginning. Of course I could easily add an option to pipe the output Wave file through SoX. But somehow I dislike the idea of adding workarounds for specific third-party applications into LamXP, especially when the problem should actually be fixed on their side... [CORRECTION] Actually ValibDec does NOT create RF64 Wave files, unless the file actually exceeds a size of 4 GB! It just inserts an empty 'JUNK' chunk at the beginning of the file as a placeholder. All compliant reading applications will later ignore that chunk. The placeholder is required, because if the file does exceed a size of 4 GB, then the 'ds64' chunk must be written to that location later on. [/CORRECTION]
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ Last edited by LoRd_MuldeR; 22nd February 2011 at 02:39. |
|
22nd February 2011, 02:18 | #155 | Link | |
Software Developer
Join Date: Jun 2005
Location: Last House on Slunk Street
Posts: 13,248
|
Quote:
http://forum.doom9.org/forum-rules.htm
__________________
Go to https://standforukraine.com/ to find legitimate Ukrainian Charities 🇺🇦✊ |
|
22nd February 2011, 03:09 | #156 | Link | ||
Registered User
Join Date: Sep 2003
Location: Berlin, Germany
Posts: 3,079
|
Quote:
Quote:
Maybe there is another point I can make to push you in my direction... LameXP is a front end for many different encoders and decoders to shield users from the various peculiarities of all these different tools. Shouldn't LameXP produce consistent output files regardless of the tools it uses in the background? If I create a Wave file from an MP3 source, it will NOT be RF64 enabled, it does not have a JUNK chunk in its header. (I did not test other source formats, but I assume they also will not have this JUNK chunk). For any source format, if I enable the resampler (SoX), then the output Wave file will not have the JUNK chunk. Only if I happen to make a straight AC3 to WAV conversion using ValDec I get these files with a JUNK chunk in the header. Anyways, it's your baby... Cheers manolito |
||
22nd February 2011, 03:49 | #157 | Link | |
Registered User
Join Date: Dec 2010
Location: california
Posts: 23
|
cpu z per request
Quote:
http://profile.imageshack.us/user/lethedoom |
|
22nd February 2011, 04:11 | #158 | Link |
Registered User
Join Date: Dec 2008
Posts: 589
|
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? |
22nd February 2011, 04:40 | #159 | Link |
Registered User
Join Date: Dec 2008
Posts: 589
|
lethedom : what he means is that it's against the rules to discuss or help people that ask for help in regard to pirated content. It's OK if you bought the DVD and wish to make backups but if you say something about downloading content without having rights to distribute it or process it, you may be banned as it's against the rules.
So getting back to your gpu-z picture. Your CPU is a i5 650 - that's dual core, but you can enable hyperthreading and have 4 cores (2 physical and 2 virtual). The two virtual cores will never be quite as fast as the real cores, as the cpu creates these two virtual cores by looking at how much each of the two real cores are loaded and then giving what the operating system assigned to a virtual core to the less used real core. Basically when a thread assigned to a real core doesn't have much to do for a few nanoseconds, the thread that was set by the operating system to run on a virtual core runs on this real core. If you'd configure a program like x264.exe (which is very optimized for multithreading) to run with 2 threads encoding something at very high quality, you'll probably see that the 2 virtual cores won't be used much, because the real cores will have very little idle time and the cpu won't find the opportunity to run threads assigned to the virtual cores on the real cores. This processor you have is designed to run each of those cores at minimum 3.2 Ghz and a maximum of 3.46 Ghz, depending on how much loaded they are. This processor is very powerful, so I would guess encoding an MP3 from a wav file would probably use about 15-20% of the cpu, maybe even less. This means that without even enabling those virtual cores, your processor could easily encode about 5 mp3 tracks at the same time, if the hard drive can keep up with reading 5 wav files from the disk at the same time. When you enable hyperthreading, you add two virtual cores to the processor, which are not as powerful as the normal physical cores as I explained above, so I would guess these two virtual cores could add up about 30% of power, allowing you to encode an additional 2 mp3 files at the same time. So in total, your processor and system could very well encode using eight threads (or eight individual files) or more and depending on the quality settings you use, maybe not even be 100% loaded, but your case is very particular - it's a very recent powerful cpu. Most people using dual core processors would have older processors that are not as powerful as yours and allowing 8 threads or more for dual core processors on those older systems would make the encoding very slow, because probably the hard disks on those systems wouldn't keep up. I'm not sure if I've explained it right but I hope it helps. Last edited by mariush; 22nd February 2011 at 04:47. |
22nd February 2011, 05:47 | #160 | Link |
Registered User
Join Date: Dec 2008
Posts: 589
|
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).
|
Tags |
aac, aotuv, flac, lame, lamexp, mp3, mp4, ogg, oggenc, opus, vorbis |
|
|