Hello.
Does anybody know why transcoding from flac to flac gives a slight increase In file size?
I noticed this when transcoding a -8 flac track to -8 flac, despite not changing anything about the file structure, tags etc..
The reason I was initially doing this was to see if I could remove embedded artwork and match the pre-embedded artwork file size by transcoding flac to flac. However i noticed an increase In file size was being observed even on a basic, minimal-tagged flac file.
The transcodes were made using dBpoweramp's music converter.
Regards
Scott
1. Post in the right place
2. Include some actual data to support/explain your claim: file sizes? magnitude of difference? version/s of FLAC used before and after? etc.
3. To remove padding, just use the official tool [font= "Courier New"]metaflac[/font], rather than pointlessly re-encoding.
For example I tried a 15mb flac 1.2.1 -8 encoded file and transcoded the file using dBpoweramp's music converter to the same flac 1.2.1, only to observe the following file difference...
15,861,375 bytes (pre-conversion)
15,877,985 bytes (post-conversion)
This sort of increase has occurred with each file I've tried, but cannot see why the two files In each case should not be exactly the same size?
Apologies for choosing the wrong thread. First post and all...
When dBpoweramp writes ID Tags to FLAC files, it adds padding.
Many thanks Spoon
But the flac.exe encoder also adds padding when encoding. Does dbpoweramp add more than 8 kB of padding ?
The encoder writes a PADDING block of 8192 bytes by default (or 65536 bytes if the input audio stream is more than 20 minutes long).
http://flac.sourceforge.net/documentation_tools_flac.html (http://flac.sourceforge.net/documentation_tools_flac.html)
Adding padding means in 8kB before the real metadata, doesn't it?
So if you write a file with 8kB padding, then you tag and stuff, including a picture bringing you over those 8kB, the tagger will have to re-write the entire file. Then the encoder writes 8 kilos of padding in addition?
But the flac.exe encoder also adds padding when encoding. Does dbpoweramp add more than 8 kB of padding ?
I know in dBpoweramp Configuration 4 kB is the default setting for FLAC.
I know in dBpoweramp Configuration 4 kB is the default setting for FLAC.
If that's the case, then the file should get smaller after re-encoding it with dbpoweramp. But it also depends on how the original file was encoded. I suppose it's possible, although unlikely, that the encoder nay have been configured to add no padding. It's also possible that the original encoding was configured to use a compression level such as -8, while the re-encoding used a lower compression level.
OP says FLAC -8 was used for both.
Cannot one use Metaflac on both files, and compare? I don't know the exact commands, but:
http://forums.mp3tag.de/index.php?showtopic=10066 (http://forums.mp3tag.de/index.php?showtopic=10066)
http://www.hydrogenaudio.org/forums/index....showtopic=65466 (http://www.hydrogenaudio.org/forums/index.php?showtopic=65466)
That's correct Porcus, both were -8 original rip and conversion process, both v.1.2.1 also.
In a further experiment I took a -8 image FLAC CD rip and converted In to -8 tracks using cue tools and the cue file and observed the following file size difference...
(262,006,650 bytes) Original Image Rip
(262,069,350 bytes) following cue tools split with cue sheet
Now this file size difference seems completely plausible as I would imagine when the file Is split to tracks the 8kb padding gets added to each track which
would account for the 60,000-odd byte difference for the sum of the 8 tracks making up the cd?
However, before I came accross cue tools I used to first convert image files to wav and then split the tracks with EAC (split wav with gaps) and then finally transcode back to FLAC tracks using dBpoweramp's music converter....A little long-winded maybe, but the filesize difference observed using this method is considerably larger following the transcode...
again..(262,006,650 bytes) Original Image Rip
and then (262,162,721 bytes) following the conversion process into FLAC tracks
That's a more considerable 156,000 bytes difference, that's almost 1.5 times extra padding per track isn't it?
Could it be then that if one were to keep transcoding the same FLAC file over and over again the file would continuously increase in size, with a new padding allocation being implemented with each transcode?
Could it be then that if one were to keep transcoding the same FLAC file over and over again the file would continuously increase in size, with a new padding allocation being implemented with each transcode?
Try!
If you want to repeat that experiment without having to wait for -8, then generate a file_0.flac with -0, a file_1.flac with -0, a file_2.flac with -0, and check the differences.
It seems the filesize does not alter after the first transcode.
I took one of the tracks split by the cuetools method from the image FLAC and transcoded it using dBpoweramp. It increased size on the first transcode, but not on a subsequent transcode of the transcode.
The same file from the longwinded method (i.e Image FLAC - convert to WAV, split with EAC and transcode back to FLAC) did not change in filesize when transcoded again.