- This topic has 14 replies, 6 voices, and was last updated 8 years, 6 months ago by
.
-
Posts
-
I mastered the skill of transferring TV recordings from the FVP4000T and started doing the same with radio recordings. {I previously transferred both for many years from an old Humax 9300}.
The mp3s I now end up with are roughly four times as large in memory usage as the equivalents used to be from the 9300
AND, rather more importantly, they DON’T work. Totally silent, delay in starting playing followed by the playing progress bar whizzing across from left to right in three or four seconds – still silent. And these are files that take up nearly 500MB per hour!
Is there a separate trick for audio files that I’ve missed. Simple dragging and dropping just isn’t working. {They do play back on the FVP4000T itself so the recording has taken place successfully}.
Any advice would be appreciated. Thanks!
I use the free tsMuxer utility to extract the audio from radio recordings (RadMac on BBC 6 Music) copied from my Foxsat HDR to my laptop which I then copy to my PMP. These work out at 212MB for a 3:06 hour recording.
TheMikeN – 15 minutes ago »
I mastered the skill of transferring TV recordings from the FVP4000T and started doing the same with radio recordings. {I previously transferred both for many years from an old Humax 9300}.
Presumably the TV recordings are playable.Both standard definition TV and radio are encrypted when recorded and so you will need to use a method that decrypts them when you download.
Are you sure that the radio recordings are decrypted?
TheMikeN – 15 minutes ago »
The mp3s I now end up with are roughly four times as large in memory usage as the equivalents used to be from the 9300
They both use basically the same format and that format is not mp3. Some mp3 players will still be able to play them though.
The reason that the FVP-4000T files are larger is that most of the mux’s epg data is also dumped into the recording, while the PVR-93000T still includes a bit too much of the epg data it does not include all of it.
To throw out the junk I make a selective copy using FFMPEG.
ffmeg.exe -i “<input_URL>” -vn -acodec copy “<output_URL>”
with the output file having a file extension of ‘mpg’.
Normally I do this through winff as winff handles batching many recordings into one long list to shrink, and it is also menu driven so that I don’t have to remember any of the nitty gritty of the ffmpeg commands if I wanted to add top and tailing or some other common options.
Both ffmeg and winff can also covert to mp3 at the same time if you want a true mp3.
Thanks everyone for joining in and advising.
The bit about file extensions almost matches with what I have discovered.
[Actually, it wasn’t me that thought of ‘my’ solution but my son who I was just taking out for driving practice before his test]. I mentioned the file sizes to him and he said ‘Hang on, that’s a bit large; have you tried changing the file extensions?}
That got me thinking that the file sizes were roughly what a lossless (WAV or FLAC) file would be – roughly 500MB for an hour.
So I came home, changed the extensions to WAV and – yippee! – everything worked. These aren’t – and never were – mp3s. The current Humax software mislabels lossless files as lossy mp3s.
So my solution has the same principles as those kindly suggested above but suggests a mislabelling bug in the current software.
Thanks again for contributions above.
One thing is certain, they will not be .WAV files. To transmit lossless audio would massively increase the bandwidth required.
The transmitted audio for radio and SD TV is heavily compressed MP2 (mpeg 1 layer 2) which has to be the format recorded (pvrs have no recoding capability, the broadcast stream is copied directly to a hard disk), heaven knows why the box says it is MP3. As Luke says the filesize is so large because of the large amount of unwanted data.
MediaInfo will confirm the actual audio details (as posted in the older linked thread).
I don’t think that’s what I meant!
Fear not, I’m not suggesting the transmission is at CD-quality/lossless/WAV/FLAC. It’s the format the recording is being stored in that I was referring to. Any lossy, primitive recording can be saved as a WAV and, when it is, the filesize becomes comparatively huge.
They may not actually be true WAV files but they play perfectly in that format… so at least the immediate problem is solved.
Whatever, the labelling of each file in the directory after transfer by Humax’s software as mp3s must be a mistake.
TheMikeN – 4 minutes ago »
the labelling of each file in the directory after transfer by Humax’s software as mp3s must be a mistake.
It is. They are MP2s but with the full now/next epg data for the multiplex that they were broadcast on. It looks as though more players can play them if they have an extension of mpg.
I suspect what is happening is that your player relaises that they are not WAV and so adjusts, but for some reason it does not come to the same conclusion if they have the extension of MP3.
The reason that they are so large is because they also include the full now/next epg for the multiplex and that epg is broadcast repeatedly throughout the programme. The increase in size has nothing to do with the actual audio parts of the recording itself as that is exactly the same as the audio part of the recording of the PVR-9300T.
TheMikeN – 25 minutes ago »
I don’t think that’s what I meant!
Fear not, I’m not suggesting the transmission is at CD-quality/lossless/WAV/FLAC. It’s the format the recording is being stored in that I was referring to. Any lossy, primitive recording can be saved as a WAV and, when it is, the filesize becomes comparatively huge.
They may not actually be true WAV files but they play perfectly in that format… so at least the immediate problem is solved.
Whatever, the labelling of each file in the directory after transfer by Humax’s software as mp3s must be a mistake.
PVR’s have no built in way of recoding any of the content they receive (Unlike DVD Recorders). It’s impossible for them to change the compression codec used for video and audio. Increasing the size (or reducing) the size of the audio content requires recoding either changing the codec and/or the bitrate used. The digital tuners simply extract the required digital content (Video, Audio, Subtitles and Audio Description data) and record it to a mass storage device (usually a hard disk). They can change the way the data is stored/packaged/multiplexed into the recorded stream (ie change the container used). Humax recorders generally store all recordings in a transport stream container (.ts).
That’s why a pvr’s recordings are 100% identical to the original broadcast. DVDr’s which do have real time mpeg encoding can change the recorded quality (and hence the filesize) on the fly and as a result are able to record from an analogue external input.
It would however be fairly trivial to change the transport stream container to programme stream (.mpg) as no actual digital recoding is required.
On other Humax recorders that allow direct export of files without any sort of change (eg the HDR-FOX-T2) when you export any recording you get a transport stream file with varying contents depending on the source (eg Freeview HD uses AAC rather than MP2 for audio compression codec).
The HDR-FOX-T2 has a excellent custom firmware add on that amongst other capability is capable of removing the extraneous data from recordings, considerably reducing the filesize in the process.
Unfortunately the 1800/2000T and 4000T model is much more locked down than the FOX T2 so especially in the case of the 4000T you can only get what the Humax software allows you to export.
If you look at the file (with any name) using MediaInfo and locate the average bitrate used for the audio track and it’s duration it’s a simple calculation to work out the filesize of the actual audio data when all the unwanted data is deleted.
I see that you know a lot more about the machine itself than I do. Thanks for the explanation.
To test it, I tried changing the extension to .ts from .wav
The files do still play properly. I’d guess they would play smoothly with many different file extensions. Seems a bit clumsy that the one they are automatically given during the transfer process (mp3) is possibly the least likely to work because of the need for LAME encoding/decoding.
So there’s one request for a very minor software update: Please get the FVP4000T to use ANY correct default file extension following audio transfers.
My other request to Humax is…
Is there any chance of having HDD settings that allow transfer of TV files a bit faster than ‘real time’? Hoping to carry and watch something I recorded the night before involves what I consider to be completely unnecessary usse of USB drives so far. Transfers straight from the HDD of a 9300T were often, quite literally twenty times faster. Wireless is nice but the process seems unnecessarily slow.
TheMikeN – 9 hours ago »
My other request to Humax is…
Is there any chance of having HDD settings that allow transfer of TV files a bit faster than ‘real time’? Hoping to carry and watch something I recorded the night before involves what I consider to be completely unnecessary usse of USB drives so far. Transfers straight from the HDD of a 9300T were often, quite literally twenty times faster. Wireless is nice but the process seems unnecessarily slow.
There is two factors here.
1 The recordings are encrypted on disk, decrypting on copying considerably slows down copying.
2 Servicing the USB port has a low priority in order to maintain the primary pvr functions.
You may like to experiment by reducing the cpu load by selecting a radio channel, an off air radio channel or even removing the aerial during copying. These have worked in the past in speeding up usb transfers from pvrs like the Humax 5200T and the Topfield 5800.
The earlier HDR-FOX-T2 is a lot more flexible especially with the custom firmware on board. To watch content on other kit you can stream directly using DLNA.
grahamlthompson – 8 hours ago — decrypting on copying considerably slows down copying.
It’s time this myth was put to rest.
There’s a simple on/off flag in one of the sidecar files.
BB – 1 minute ago »
grahamlthompson – 8 hours ago — decrypting on copying considerably slows down copying.
It’s time this myth was put to rest.
There’s a simple on/off flag in one of the sidecar files.
The simple on/off does not actually decrypt the file it merely allows the box to decrypt it during the copying process. Decryption requires a complete rewrite of the data, it’s not a on/off switch.
In any case pretty sure the on/off switch refers to the HDR-FOX-T2. 1800T and 2000T .hmt files. The format of these is well known.
Afaik no one has been able to access the sidecar files on a 4000T which like Humax 2nd generation Freesat boxes is locked down completely (thought to be LUKS encrypted).
It’s no myth, the CF for the HDR-FOX-T2 (Which is recording the same content) is capable of decrypting content in situ. Decrypted files copy to usb very much faster than ones that remain encrypted. In fact because the bog standard HDR-FOX-T2 will decrypt SD, but not HD on copying to usb, then copying HD is much faster than SD.
BB – 25 minutes ago »
grahamlthompson – 8 hours ago — decrypting on copying considerably slows down copying.
It’s time this myth was put to rest.
There’s a simple on/off flag in one of the sidecar files.
Please would you clarify what aspect is a myth?
BB – 1 hour ago »
grahamlthompson – 8 hours ago — decrypting on copying considerably slows down copying.
It’s time this myth was put to rest.
There’s a simple on/off flag in one of the sidecar files.
Nonsense. The flag simply says whether or not encryption can be removed (as standard SD recordings can be decrypted and HD cannot). Changing it does nothing to actually remove the encryption.
- You must be logged in to reply to this topic.